rest - una - tipos de datos de cadenas de carácter
¿URLs tranquilas con datos en cadena de consulta o cuerpo de solicitud? (4)
¿Cuál es la regla general para pasar datos en una URL REST en la cadena de consulta frente al cuerpo de una solicitud?
Es decir: está creando un servicio para agregar jugadores de hockey. Podrías ir con:
PUT /players
{ "name": Gretzky }
o
PUT /players?name=Gretzky
Si está transfiriendo una gran cantidad de datos, debería ir con la opción n. ° 1, ya que existe un límite en la longitud de la URL. Pero aparte de esto, ¿por qué no usar la cadena de consulta para pasar datos?
Actualización : se eliminó el comentario de que se podía probar la opción n. ° 2 en un navegador. Se dio cuenta (duh) de que solo puede hacer GET-s en su navegador.
La URL utilizada debería identificar el recurso en el cuerpo, ya sea por componentes de ruta o parámetros de consulta, aunque preferiría componentes de ruta para algo así como un nombre o id. El cuerpo debe ser una representación; el que PONE debe ser igual o similar a lo que OBTENGA de la misma URL (o puede obtener, en el caso de formatos múltiples)
El ejemplo n. ° 1 es inapropiado porque está enviando una representación de un jugador a una url para todos los jugadores. POST sería más apropiado en este caso.
El ejemplo n. ° 2 sería un poco inapropiado si se extendiera a todos los campos porque entonces estarías enviando datos de representación en la url.
Mi comprensión de las operaciones REST es que la URL identifica de manera única el recurso, mientras que el cuerpo de la solicitud contiene la representación del recurso. Dado eso, es cuestionable si alguna de sus opciones es realmente RESTful.
El primero sería, asumiendo que el recurso se llame "Jugadores" y un GET en ese recurso devuelva una lista de jugadores (no entraré en la cuestión de si ese GET devuelve otras URL de recursos o no ... Fielding diría que debería, con solicitudes individuales para obtener los datos del recurso).
El segundo sería, suponiendo que el cuerpo de la solicitud contenga información con el nombre "Gretsky". Sin embargo, eso requiere que generes las claves externamente.
Según la definición de HTTP de PUT, su primera solicitud sobrescribe la lista de jugadores con una nueva lista que contiene solo un nombre de jugador. No está agregando a la lista de jugadores.
La segunda opción realmente no tiene mucho sentido para mí. Hacer PUT sin cuerpo no es realmente coherente con el significado de PUT.
Teniendo en cuenta que una de las definiciones estándar de POST es agregar a un recurso existente, no estoy seguro de por qué no lo haría
POST /players
{ "name": Gretzky }
Si está seguro de que todos los nombres de sus jugadores serán únicos, podría usar PUT así:
PUT /player/Gretzky
{ "name": Gretzky }
Cuando decide realizar REST en HTTP, acepta utilizar HTTP de la manera definida en RFC2616. Eso es lo que significa la restricción de interfaz uniforme. Y para ser pedante, no existe una URL REST y no se puede probar ninguna de las opciones en un navegador porque sin javascript, no se puede hacer un PUT en un navegador.
La opción n. ° 1 está bien, aunque probablemente sea excesiva. La opción n. ° 1 no está bien porque no es idempotente.
La opción n. ° 2 es una idea MALA . Eso sería mal uso PUT. PUT debe usarse principalmente cuando la carga de datos de su solicitud es un bloque opaco de datos, generalmente grande o jerárquico. Las cargas útiles más pequeñas y no jerárquicas tienen más sentido que POST.
Además, intente evitar el cambio de estado a través de parámetros de consulta. No hay nada técnicamente peligroso al respecto si no se trata de una solicitud GET, pero en realidad no es RESTful.
En este caso, lo que debes hacer es:
POST /players HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 12
name=Gretsky
Esto debería devolver una respuesta 201 Created . (Hay una excepción a esto: si no crea el recurso de inmediato, y podría ser rechazado en el futuro, utilice 202 Accepted lugar).
Escribir un servicio web REST que use más HTTP que POST y GET solo debe hacerse después de haber leído la especificación HTTP . (Es una lectura muy útil). Esa regla es un poco más flexible si usa un marco que toma todas las decisiones por usted.