¿Cuál debería ser el estándar para las URL ReSTful?

Como no puedo encontrar un trabajo chuffing, he estado leyendo en ReST y creando servicios web. Tal como lo interpreté, el futuro se trata de crear un servicio web para todos sus datos antes de construir la aplicación web. Lo cual parece una buena idea.¿Cuál debería ser el estándar para las URL ReSTful?

Sin embargo, parece haber muchas ideas contradictorias sobre cuál es el mejor esquema para las URL ReSTful.

Algunas personas abogan por URLs bastante simple

http://api.myapp.com/resource/1

Además, algunas personas les gusta agregar la versión de la API a la URL como tal

http://api.myapp.com/v1/resource/1

Y para hacer las cosas aún más confuso, Algunas personas abogan por agregar el tipo de contenido para obtener las solicitudes

http://api.myapp.com/v1/resource/1.xml 
http://api.myapp.com/v1/resource/1.json 
http://api.myapp.com/v1/resource/1.txt

Mientras que otros piensan que el tipo de contenido debe enviarse en el encabezado HTTP.

Soooooooo ... Es una gran variación, lo que me ha dejado inseguro de cuál es el mejor esquema de URL. Personalmente, veo los méritos de la URL más completa que incluye un número de versión, un localizador de recursos y un tipo de contenido, pero soy nuevo en esto, así que podría estar equivocado.

Por otro lado, podría argumentar que debe hacer "lo que mejor funcione para usted". Pero eso realmente no encaja con la mentalidad ReST en lo que puedo decir, ya que el objetivo es tener un estándar.

Y como muchos de ustedes tendrán más experiencia que yo con ReST, pensé que les pediría orientación. Entonces, con todo eso en mente ...

¿Cuál debería ser el estándar para las URLs retentivas?

Fuente

2009-10-08 gargantuan

Considere la posibilidad de corregir el título. "lo mejor" no significa nada. Y tu pregunta es mucho más específica que un vago saludo con la mano. Tienes dos preguntas específicas sobre el verbo y el formato de respuesta. Por favor, corrija el título de su pregunta para reflejar claramente su pregunta real. –

Bienvenido al mundo confuso de lo que es y lo que no es REST. Primero sugeriría que ha estado leyendo sobre REST en los lugares equivocados. Pruebe RESTWiki como un buen punto de partida.

REST no es una gran solución para la entrega de servicios de datos para su aplicación web. Los "servicios web" (también conocidos como SOAP, XML-RPC, WSDL, HTTP-POX) pueden ser útiles, pero el estilo arquitectónico REST está mucho más orientado a los escenarios cliente-servidor que a los escenarios de servidor-servidor.

Deja de pensar en cómo se ven las URL. Lo que parecen tiene mucho más que ver con qué marco de servidor se usa para implementar el servicio RESTful que con el diseño del servicio en sí. El cliente debe descubrir las URL de las representaciones recuperadas anteriormente, por lo que realmente no le importa cómo se vean las URL.

Habiendo dicho eso, usando sus URL de ejemplo para tratar de distinguir lo que cree que deberían ser recursos diferentes, tengo algunas otras sugerencias.

No utilice recursos de la versión. es decir, si tiene un recurso al que se accede mediante la url http://example.org/TodaysWeather, nunca cree un recurso en http://example.org/V2/TodaysWeather. Hay muchas otras formas mejores de representar versiones que crear un recurso completamente nuevo. Busque SO para muchas otras discusiones sobre esto.

En cuanto a la creación de diferentes recursos para diferentes tipos de contenido, creo que es una decisión específica del contexto. Si su usuario final está utilizando un navegador para acceder al servicio REST y son lo suficientemente sofisticados como para entender la diferencia entre JSON y XML, entonces continúe y cree dos recursos. Si es un cliente de máquina, entonces usaría la negociación de contenido para obtener el formato requerido.

Y, por último, tenga cuidado, dado que REST se convirtió en una palabra de moda du jour, hay mucho más contenido mal informado que contenido válido.

Fuente

2009-10-08 12:49:52

Gran parte es subjetiva, creo. Semánticamente, no es explícita la versión de los recursos particulares, a menos que sea una parte real del problema comercial (es decir, quiero ver mi recurso InsuranceCoverage como lo fue hace dos años, no ahora). Pero yo diría que empujar una "v1" al comienzo de la URL hace que sea explícita la versión de la API con la que está hablando. También puede imaginarse cómo el código del servidor sería ordenado: el código V1 no se modifica cuando se crea V2 porque esas son todas las clases nuevas, no es necesario insertar una instrucción switch en un encabezado de Versión en la solicitud. –

Cuando la mayoría de la gente habla de versiones, no se refieren a versiones "relevantes para el negocio". Sin embargo, tienes razón, si es relevante para el negocio, entonces tiene sentido que sea un recurso diferente. La adición de versiones a los URI se vuelve realmente complicada cuando se usa hipermedia correctamente y solo una parte de su API necesita una nueva versión. Ahora tiene representaciones a las que se accede con las URL de V2 que apuntan a los recursos de la API V1. –

En cuanto a ser ordenado en el lado del servidor, los tipos de medios de versionado pueden ser igualmente fáciles de separar. En general, ya existe un mecanismo para "activar" el tipo de contenido, por lo que agregar una versión al tipo de contenido solo reutiliza ese mecanismo para entregar la versión correcta. –

El verbo no se puede poner en la URL. Eso no tiene sentido. Ya está en el encabezado de solicitud. Cuando envía una solicitud POST que tiene GET en la URL, eso es una locura.

El formato de respuesta generalmente se coloca mejor en la URL porque los encabezados no proporcionan un lugar simple e inequívoco para poner esa información.

Fuente

2009-10-08 11:15:37

tiene razón, leí mal este artículo y lo tomé al valor nominal http://microformats.org/wiki/rest/urls – gargantuan

A su segunda frase, "El formato de respuesta generalmente se coloca mejor en la URL porque los encabezados no Proporcionamos un lugar simple e inequívoco para poner esa información ". -- ¡por supuesto que lo hacen! Aceptar es exactamente eso y está muy bien soportado. –

Estoy con S.Lott - el verbo * no debe * estar allí, ya que desea utilizar la misma URL para leer el registro y actualizarlo para que califique como REST.

El tipo de contenido es algo más para dejar de lado, ya que es el mismo registro, pero con múltiples formatos de codificación. (Lea en FRBR por mucho más de lo que siempre quiso saber sobre los problemas de la distinción). La decisión de qué versión enviar en respuesta puede manejarse con encabezados HTTP Accept.

El único en el que estoy desgarrado es el número de versión, ya que personalmente no puedo pensar en un encabezado HTTP apropiado para manejar ese aspecto del mismo. (Esperar? Aceptar-Codificar? Pragma? Tal vez incluso actualizar, pero con mayor frecuencia desea degradar a una versión anterior por razones de compatibilidad, creo) Probablemente tendría un acceso sin versión que dio el más reciente versión de producción, pero podría considerar tener una versión para cambios significativos que no fueran compatibles con versiones anteriores.

actualización: la versión depende probablemente de cuánto control tenga sobre los clientes que se conectan a sus servicios ...si tiene acceso de un público amplio (que yo no), es posible que esté más interesado en la compatibilidad con versiones anteriores. Dependiendo de los cambios realizados, es posible que también considere la 'versión 2' como un recurso completamente nuevo, en lugar de una nueva 'versión' del original.

Fuente

2009-10-08 11:29:50 Joe

no tendría un número de versión opcional ¿hace que mod_rewrite y el enrutamiento sean más difíciles? Además, al tener el número de versión allí, sería más fácil para las personas actualizar y degradar al tener la versión api requerida en una correa de arranque, en lugar de tener que cambiar cada solicitud a mano. – gargantuan

Content-type es el encabezado que usaría si desea que su servidor pueda entregar dos versiones diferentes de una representación. p.ej. aplicación/vnd.twitter.statusesV1 + xml y application/vnd.twitter.statusesV2 + xml Con este enfoque, el cliente puede solicitar la versión que entienden y se pueden introducir nuevas versiones sin romper clientes. Obviamente, el tipo de medio debe diseñarse, en primer lugar, para ser lo más resistente posible a los cambios, y la introducción de un nuevo número de versión solo debería ser el último recurso cuando rompa a los clientes antiguos. –

Darrel: el encabezado HTTP 'Aceptar' es lo que usaría el cliente para especificar qué tipos desea consumir, y luego el servidor respondería (configurando el tipo de contenido según corresponda) o con un estado de 406 (no aceptable)) – Joe

Versiones: Por lo general, he visto esto colocado donde lo tiene en su URL de ejemplo, y si no se especifica una versión, debe responder con la versión de producción más reciente. Una consideración es si poner la versión de API en su cadena de respuesta para depuración de clientes.

Formatos de respuesta: El formato de devolución debe especificarse en el encabezado HTTP Accept enviado por el agente de usuario.

Verbos en la cadena de solicitud: Absolutamente no.

Fuente

2009-10-08 11:34:11 Nicholas

¿No hay un argumento para la usabilidad? La URL es parte de la interfaz de usuario si se accede al servicio a través de un navegador. Entonces, aunque debería estar en el encabezado HTTP Accept, podría haber un beneficio al tenerlo también en la url. – gargantuan

En ese caso, creo que el problema real de usabilidad se produce cuando tienes JSON en el encabezado de aceptación y XML en la url. – Nicholas

Si toma una API anterior y agrega una nueva (donde no se especificó previamente ningún parámetro de versión), le sugiero que, si recibe una solicitud sin un parámetro de versión, responda con la versión más antigua de su API en lugar de lo más nuevo; de lo contrario, romperás clientes mayores. Sin embargo, si este tipo de comportamiento "más reciente" se hubiera especificado desde la V1 de la API, estaría bien. Mis dos centavos. –

¿Cuál debería ser el estándar para las URL ReSTful?

Respuesta

Cuestiones relacionadas