siglas - rest vs soap

Estándar de reposo: parámetros de ruta o parámetros de solicitud (6)

Creo que eso depende Una URL para un recurso. Si desea recibir ese recurso de una manera ligeramente diferente, dele una cadena de consulta. Pero para un valor que entregue un recurso diferente, póngalo en el camino.

Entonces, en su ejemplo, el valor de la variable está directamente relacionado con el recurso que se devuelve. Entonces tiene más sentido en el camino.

Estoy creando un nuevo servicio REST.

¿Cuál es el estándar para pasar parámetros a los servicios REST? Desde diferentes implementaciones REST en Java, puede configurar parámetros como parte de la ruta o como parámetros de solicitud. Por ejemplo,

Parámetros de ruta http://www.rest.services.com/item/b

Parámetros de solicitud http://www.rest.services.com/get?item=b

¿Alguien sabe cuáles son las ventajas / desventajas para cada método de pasar parámetros? Parece que pasar los parámetros como parte de la ruta parece coincidir mejor con la noción del protocolo REST. Es decir, una sola ubicación significa una respuesta única, ¿correcto?

Esta es una gran pregunta fundamental. Recientemente llegué a la conclusión de evitar los parámetros de ruta. Conducen a una resolución de recursos ambigua. La URL es básicamente el ''nombre de método'' de un fragmento de código que se ejecuta en algún lugar de un servidor. Prefiero no mezclar nombres de variables con nombres de métodos. El nombre de su método es aparentemente ''cliente'' (que en mi humilde opinión es un nombre podrido para un método, pero a las personas de REST les encanta este patrón). El parámetro que está pasando a este método es el nombre del cliente. Un parámetro de consulta funciona bien para eso, y este recurso y el valor del parámetro de consulta incluso se pueden almacenar en caché si se desea.

No hay un recurso físico de cliente de TI. Es probable que no haya ningún archivo en el disco debajo de una carpeta del cliente que lleva el nombre del cliente. Este es un servicio web que realiza algún tipo de transacción de base de datos. El ''recurso'' es su servicio, no el cliente.

Esta obsesión por REST y web-verbs me recuerda los primeros días de la programación orientada a objetos donde intentamos meter nuestro código en representaciones virtuales de objetos físicos. Luego nos dimos cuenta de que los objetos generalmente son conceptos virtuales en un sistema. OO sigue siendo útil cuando se hace de la manera correcta. REST también es útil si te das cuenta de que los recursos RESTful son servicios, no objetos.

La primera variación es un poco más clara, y le permite reservar los parámetros de solicitud para cosas como el orden y la página, como en

http://www.rest.services.com/items/b?sort=ascending;page=6

Las rutas tienden a almacenarse en caché, los parámetros tienden a no ser, como regla general.

Asi que...

GET /customers/bob

GET /customers?name=bob

El primero es más probable que se almacene en caché (asumiendo encabezados adecuados, etc.) mientras que el último es probable que no se guarde en caché.

Su segundo ejemplo de "parámetros de solicitud" no es correcto porque "get" se incluye como parte de la ruta. GET es el tipo de solicitud, no debe ser parte de la ruta.

Hay 4 tipos principales de solicitudes:

GET PUT POST DELETE

Las solicitudes GET siempre deben poder completarse sin información en el cuerpo de la solicitud. Además, las solicitudes GET deben ser "seguras", lo que significa que la solicitud no modifica los datos significativos.

Además de la preocupación de almacenamiento en caché mencionado anteriormente, los parámetros en la ruta de la URL tendrían que ser requeridos y / o esperados porque también son parte de su enrutamiento, mientras que los parámetros pasados en la cadena de consulta son más variables y no afectan la parte de su aplicación la solicitud se dirige a. Aunque también podría pasar un conjunto de parámetros de longitud variable a través de la url:

GET somedomain.com/states/Virginia,California,Mississippi/

Un buen libro para leer como introducción a este tema es "Restful Web Services" . Aunque te advertiré que estés preparado para echarle un vistazo a información redundante.

tl; dr: Es posible que desee los dos.

El artículo # 42 existe:

GET /items/42 Accept: application/vnd.foo.item+json --> 200 OK { "id": 42, "bar": "baz" } GET /items?id=42 Accept: application/vnd.foo.item-list+json --> 200 OK [ { "id": 42, "bar": "baz" } ]

El artículo # 99 no existe:

GET /items/99 Accept: application/vnd.foo.item+json --> 404 Not Found GET /items?id=99 Accept: application/vnd.foo.item-list+json --> 200 OK [ ]

Explicaciones y comentarios

/items/{id} devuelve un item mientras /items?id={id} devuelve una item-list .
Incluso si solo hay un elemento único en una item-list filtrada, se devuelve una lista de un solo elemento para garantizar la coherencia (en contraposición con el elemento en sí).
Simplemente sucede que id es una propiedad única. Si tuviéramos que filtrar otras propiedades, esto funcionaría exactamente de la misma manera.
Los elementos de un recurso de recopilación solo pueden nombrarse utilizando propiedades únicas (por ejemplo, claves como un subrecurso de la colección) por razones obvias (son recursos normales y los URI identifican recursos de manera única).
Si el elemento no se encuentra al usar un filtro, la respuesta sigue siendo OK y aún contiene una lista (aunque vacía). El hecho de que solicitemos una lista filtrada que contiene un elemento que no existe no significa que la lista en sí no exista.

Debido a que son tan diferentes e independientemente útiles, es posible que desee ambos . El cliente querrá diferenciar entre todos los casos (por ejemplo, si la lista está vacía o la lista en sí misma no existe, en cuyo caso debe devolver un 404 para /items?... ).

Descargo de responsabilidad: este enfoque no es de ninguna manera "estándar". Sin embargo, tiene tanto sentido para mí que me dio ganas de compartir.

PD: nombrar la colección de elementos "obtener" es un olor a código; prefiere "artículos" o similar.