Nuestros mejores programadores han agotado sus provisiones de café, por su búsqueda diariamente por la respuesta, hasta que Marcos encontró la solución en Gogs por lo tanto hoy la comparte contigo.
Solución:
En este documento Guía de estilo JSON de Google (recomendaciones para crear API JSON en Google),
Recomienda que:
-
Los nombres de propiedad deben ser camello, Cadenas ASCII.
-
El primer carácter debe ser una letra, un guión bajo (_) o un signo de dólar ($).
Ejemplo:
"thisPropertyIsAnIdentifier": "identifier value"
Mi equipo sigue esta convención.
No existe un estándar ÚNICO, pero he visto 3 estilos que menciona (“Pascal / Microsoft”, “Java” (camelCase) y “C” (guiones bajos, snake_case)) – así como al menos uno más, kebab-case igual que longer-name).
En su mayoría, parece depender de los antecedentes que tuvieran los desarrolladores del servicio en cuestión; aquellos con antecedentes de c / c ++ (o lenguajes que adoptan nombres similares, que incluyen muchos lenguajes de scripting, ruby, etc.) a menudo eligen la variante de subrayado; y descansar de manera similar (Java vs .NET). La biblioteca Jackson que se mencionó, por ejemplo, asume la convención de nomenclatura de los beans de Java (camelCase)
ACTUALIZACIÓN: mi definición de “estándar” es una convención ÚNICA. Por tanto, si bien uno podría afirmar “sí, hay muchos estándares”, para mí hay varios Naming Conventions, ninguno de los cuales es “El” estándar en general. Uno de ellos podría considerarse el estándar para una plataforma específica, pero dado que JSON se usa para la interoperabilidad entre plataformas, esto puede o no tener mucho sentido.
Premisa
Hay sin nombre estándar de keys en JSON. De acuerdo con la Objetos sección de la especificación:
La sintaxis JSON no impone ninguna restricción sobre las cadenas utilizadas como nombres, …
Lo que significa el caso de Carmel o caso_serpiente debería funcionar bien.
Factores impulsores
Imponer una convención de nomenclatura JSON es muy confuso. Sin embargo, esto se puede resolver fácilmente si lo descompone en componentes.
-
Lenguaje de programación para generar JSON
- Python – caso_serpiente
- PHP – estuche_serpiente
- Java – camelCase
- JavaScript – camelCase
-
JSON en sí no tiene un nombre estándar de keys
-
Lenguaje de programación para analizar JSON
- Python – caso_serpiente
- PHP – estuche_serpiente
- Java – camelCase
- JavaScript – camelCase
Mezclar los componentes
- Pitón »JSON» Pitón – caso_serpiente – unánime
- Pitón »JSON» PHP – caso_serpiente – unánime
- Pitón »JSON» Java – caso_serpiente – por favor vea el Problema de Java debajo
- Pitón »JSON» JavaScript – caso_serpiente tendrá sentido atornillar el front-end de todos modos
- Pitón »JSON» no lo sabe – caso_serpiente tendrá sentido al diablo con el analizador de todos modos
- PHP »JSON» Pitón – caso_serpiente – unánime
- PHP »JSON» PHP – caso_serpiente – unánime
- PHP »JSON» Java – caso_serpiente – por favor vea el Problema de Java debajo
- PHP »JSON» JavaScript – caso_serpiente tendrá sentido atornillar el front-end de todos modos
- PHP »JSON» no lo sabe – caso_serpiente tendrá sentido al diablo con el analizador de todos modos
- Java »JSON» Pitón – caso_serpiente – por favor vea el Problema de Java debajo
- Java »JSON» PHP – caso_serpiente – por favor vea el Problema de Java debajo
- Java »JSON» Java – el caso de Carmel – unánime
- Java »JSON» JavaScript – el caso de Carmel – unánime
- Java »JSON» no lo sabe – el caso de Carmel tendrá sentido al diablo con el analizador de todos modos
- JavaScript »JSON» Pitón – caso_serpiente tendrá sentido atornillar el front-end de todos modos
- JavaScript »JSON» PHP – caso_serpiente tendrá sentido atornillar el front-end de todos modos
- JavaScript »JSON» Java – el caso de Carmel – unánime
- JavaScript »JSON» JavaScript – el caso de Carmel – original
Problema de Java
caso_serpiente todavía tendrá sentido para aquellos con entradas de Java porque las bibliotecas JSON existentes para Java están utilizando solo métodos para acceder a la keys en lugar de usar el estándar dot.syntax. Esto significa que no le haría ningún daño a Java acceder a la encastrado de serpiente keys en comparación con el otro lenguaje de programación que puede hacer el dot.syntax.
Ejemplo para Javaorg.jsonpaquete
JsonObject.getString("snake_cased_key")
Ejemplo para Javacom.google.gsonpaquete
JsonElement.getAsString("snake_cased_key")
Algunas implementaciones reales
- API de JavaScript de Google Maps – camello
- API de JavaScript de Facebook – serpiente_cased
- Servicios web de Amazon – encastrado de serpiente Y camello
- API de Twitter – encastrado de serpiente
- JSON-LD: camello Y AdecuadoCamelCasado
Conclusiones
La elección de la convención de nomenclatura JSON correcta para su implementación JSON depende de su pila de tecnología. Hay casos en los que se puede utilizar caso_serpiente, el caso de Carmel, o cualquier otra convención de nomenclatura.
Otra cosa a considerar es el peso que se le asignará al generador de JSON frente al analizador de JSON y / o al JavaScript de front-end. En general, se debe poner más peso en el lado del generador JSON en lugar del lado del analizador JSON. Esto se debe a que la lógica empresarial generalmente reside en el lado del generador de JSON.
Además, si se desconoce el lado del analizador JSON, puede declarar lo que pueda funcionar para usted.
Aquí tienes las comentarios y calificaciones
Al final de todo puedes encontrar las explicaciones de otros administradores, tú asimismo tienes la libertad de dejar el tuyo si lo deseas.