underscore restful resource pattern guidelines camelcase api url rest uri restful-url

api - restful - ¿Guión, guión bajo o camelCase como delimitador de palabras en URI?



rest url pattern (5)

Aquí está lo mejor de ambos mundos.

También "me gusta" subraya, además de todos sus puntos positivos sobre ellos, también hay un cierto estilo de la vieja escuela para ellos.

Entonces, lo que hago es usar guiones bajos y simplemente agregar una pequeña regla de reescritura al archivo .htaccess de Apache para volver a escribir todos los guiones bajos en guiones.

https://yoast.com/apache-rewrite-dash-underscore/

Estoy diseñando una API basada en HTTP para una aplicación de intranet. Me doy cuenta de que es una preocupación bastante pequeña en el gran esquema de las cosas, pero: ¿debo usar guiones, guiones bajos o camelCase para delimitar palabras en los URI?

Aquí están mis pensamientos iniciales:

el caso de Carmel

  • posibles problemas si el servidor no distingue entre mayúsculas y minúsculas
  • Parece tener un uso bastante generalizado en las claves de cadena de consulta ( http://api.example.com ? searchQuery = ...), pero no en otras partes de URI

Guión

  • Más estéticamente agradable que las otras alternativas.
  • Parece ser ampliamente utilizado en la parte de la ruta de la URI
  • nunca visto la clave de cadena de consulta con guiones en el comodín
  • posiblemente mejor para SEO (esto puede ser un mito)

Guion bajo

  • potencialmente más fácil para los lenguajes de programación para manejar
  • varias API populares (Facebook, Netflix, StackExchange, etc.) están usando guiones bajos en todas las partes de la URI.

Me estoy inclinando hacia guiones bajos para todo. El hecho de que la mayoría de los grandes jugadores los estén utilizando es convincente (consulte https://stackoverflow.com/a/608458/360570 ).

Debe usar guiones en una URL de aplicación web rastreable. ¿Por qué? Porque el guión separa las palabras (para que un motor de búsqueda pueda indexar las palabras individuales), y no es un carácter de palabra . El subrayado es un carácter de palabra, lo que significa que debe considerarse parte de una palabra.

Haga doble clic en esto en Chrome: camelCase
Haga doble clic en esto en Chrome: under_score
Haga doble clic en esto en Chrome: con guión.

¿Ves cómo Chrome (oigo que Google también hace un motor de búsqueda) solo piensa que una de esas son dos palabras?

camelCase y el underscore también requieren que el usuario use la tecla de mayúsculas , mientras que el hyphenated no lo hace.

Entonces, si debería usar guiones en una aplicación web rastreable, ¿por qué se molestaría en hacer algo diferente en una aplicación de intranet? Una cosa menos para recordar.

En general, no tendrá suficiente impacto de qué preocuparse, particularmente porque es una aplicación de intranet y no una aplicación de Internet de uso general. En particular, debido a que es intranet , el SEO no es una preocupación, ya que su intranet no debería ser accesible a los motores de búsqueda. (Y si lo es, no es una aplicación de intranet).

Y cualquier marco que valga la pena tenerlo ya tiene una forma predeterminada de hacerlo, o es bastante fácil cambiar la forma en que trata los componentes de URL de varias palabras, por lo que no me preocuparía demasiado.

Dicho esto, así es como veo las distintas opciones:

Guión

  • El mayor peligro para los guiones es que el mismo carácter (normalmente) también se usa para la resta y la negación numérica (es decir, menos o negativo ).
  • Los guiones se sienten incómodos en los componentes de URL. Parece que solo tienen sentido al final de una URL para separar las palabras en el título de un artículo. O, por ejemplo, el título de una pregunta de desbordamiento de pila que se agrega al final de una URL para fines de SEO y claridad del usuario.

Guion bajo

  • Una vez más, se sienten mal en los componentes de la URL. Rompen el flujo (y la belleza / simplicidad) de una URL, ya que esencialmente agregan un espacio grande y aparente en medio de una URL limpia y fluida.
  • Tienden a mezclarse con los subrayados. Si espera que sus usuarios copien y peguen sus URL en MS Word u otros programas similares de edición de texto, o en cualquier otro lugar que pueda recoger una URL y diseñe un estilo con un subrayado (como los enlaces tradicionalmente ), entonces es posible que desee Evite los guiones bajos como separadores de palabras. Particularmente cuando se imprime, una URL subrayada con guiones bajos parece que tiene espacios en lugar de guiones bajos.

El caso de Carmel

  • Por mucho, mi favorito, ya que hace que las URL parezcan fluir mejor y no tiene ninguna de las fallas que tienen las dos opciones anteriores.
  • Puede ser un poco más difícil de leer para las personas que tienen dificultades para diferenciar mayúsculas y minúsculas, pero esto no debería ser un gran problema en una URL, porque la mayoría de las "palabras" deben ser componentes de la URL y estar separados por una / de todos modos Si descubre que tiene un componente de URL que tiene más de 2 "palabras" de longitud, probablemente debería tratar de encontrar un nombre mejor para ese concepto.
  • Tiene un posible problema con la sensibilidad a las mayúsculas y minúsculas, pero la mayoría de las plataformas se pueden ajustar para que sean sensibles a las mayúsculas y minúsculas. Cualquiera es solo un problema para 2 casos: a.) Personas que escriben la URL, y b.) Programadores (ya que no somos humanos) que escriben la URL. No es diferente que todo un caso.

Mientras recomiendo los guiones, también postularé una respuesta que no está en su lista:

Nada en absoluto

  • La API de mi empresa tiene URI como /quotationrequests/ , /purchaseorders/ y así sucesivamente.
  • A pesar de que usted dijo que era una aplicación de intranet, mencionó SEO como un beneficio. Google hace coincidir el patrón / foobar / en una URL para una consulta de ?q=foo+bar
  • Realmente espero que no consideres ejecutar una llamada PHP a ninguna cadena arbitraria que el usuario pase a la barra de direcciones, como sugiere @ ServAce85.