Pregunta de DESCANSO: ¿PONER una representación, OBTENER una diferente?

Question

Versión corta de la pregunta:
¿Es necesario que "OBTENER" en un URI particular coincida con lo que se "PUSÓ" a ese URI?

Creo que no. He aquí por qué:

Dado que un recurso es algo abstracto que el cliente no puede conocer teóricamente, cuando hacemos un PUT, solo debemos enviar una representación. Basado en peinar sobre RFC2616, no parece completamente especificado en cuanto a lo que eso significa para un recurso que tiene muchas representaciones (¿potencialmente infinitas?), Pero aquí están mis pensamientos; por favor dígame si está de acuerdo:

Mi expectativa es que si PONGO una representación a un recurso, todas las demás representaciones del recurso en ese URI deben mantenerse consistentes (potencialmente actualizadas) según sea necesario. En otras palabras, le está diciendo al recurso "use esta representación para redefinirse".

Por lo tanto, yo debería ser capaz de hacer esto:

PUT/recursos/foo/myvacation
Content-type: image/jpg
...

y seguimiento con esto:

GET/recursos/foo/myvacation
Aceptar: image/png
...

y obtener la versión actualizada de myvacation en un formato diferente (asumiendo que el servidor sabe cómo hacerlo). La extrapolación de eso, este compuesto atómica PUT "imagen + metadatos" también debería ser legal:

PUT/recursos/foo/myvacation
Content-type: multipart/form-data

Content-disposition: datos de formulario; name = "document"
Content-type: image/jpg
[..]
Content-disposition: form-data; name = "iptc"
Tipo de contenido: application/iptc
[..]
Content-disposition: form-data; name = "Exif"
Content-type: application/Exif
[..]

Y entonces, porque la negociación de contenido del lado del servidor (RFC2616 sección 12.1) puede tener lugar sobre la base de casi cualquier cosa, nos puede por defecto en el "documento" contenido para esto:

GET/recursos/foo/myvacation
Content-type: image/jpg
[..]

o si cree lo mismo que yo hago esa RFC 2396 sección 3.4 "El componente de consulta es una cadena de información para ser interpretada por el recurso". significa que un URI con una cadena de consulta se refiere al mismo recurso que un URI sin una cadena de consulta (y es isomorfo con solo enviar datos application/x-form-urlencoded al recurso), entonces esto también debería ser legal:

?

GET/recursos/foo/myvacation content = Exif
Content-Type: application/Exif
[..]

La descripción de PUT dice:

El método PUT solicitudes que el adjunto d entidad se almacena bajo el Request-URI proporcionado.

Para mí, esto es bastante anti-DESCANSO, a menos que lo leas de manera muy liberal. Mi interpretación es "El método PUT solicita que se cree o actualice un recurso en el URI de solicitud proporcionado en función de la representación de la entidad adjunta".

Más adelante, obtenemos:

La diferencia fundamental entre el POST y PUT solicitudes se refleja en el significado diferente de la Solicitud-URI. El URI en una solicitud POST identifica el recurso que manejará la entidad adjunta. Ese recurso puede ser un proceso de aceptación de datos, una puerta de enlace a algún otro protocolo o una entidad separada que acepta anotaciones. Por el contrario, el URI en una solicitud PUT identifica la entidad adjunta a la solicitud: el agente de usuario sabe qué URI está destinado y el servidor NO DEBE intentar aplicar la solicitud a algún otro recurso.

Tenemos que leer esto de forma similar, pero las partes clave aquí son "sabe qué URI está destinado" y "aplica la solicitud".

Por lo tanto, para mí, la representación devuelta por GET en un URI determinado no tiene que ser necesariamente la misma representación que se PON en el URI dado, solo tiene que ser coherente.

¿Es verdadero o no?

Answer 1

Si se está transformando, tendría sentido que PUT no sea lo que , así que no veo por qué es un problema.

Pero, si PUT un usuario con cierta información, a continuación, cuando se utiliza GET entonces se debe recuperar esa persona, del mismo modo, cuando pongo mi foto de las vacaciones cuarto, cuando llamo GET espero que la foto, pero puede transformarse mediante la conversión a un formato diferente, o tener algunas otras transformaciones, pero, si obtengo la quinta foto, entonces eso es un problema.

Answer 2

Basado en el hecho de que la negociación de contenido puede devolver diferentes representaciones del mismo URI, estoy bastante seguro de que lo que usted PONE no tiene que ser igual a lo que recupera.

Answer 3

Sus suposiciones son correctas. El GET no tiene necesariamente que devolver la misma representación que PUT, pero tiene que ser el mismo recurso .

Actualmente estoy trabajando en una aplicación web que devolverá cualquier recurso como XHTML, JSON o un dialecto XML personalizado, dependiendo de lo que pida en los encabezados de negociación de contenido. Entonces, un navegador verá el HTML por defecto.Otros clientes HTTP, incluido XMLHttpRequest, pueden obtener el JSON, y así sucesivamente. Todos son representaciones del mismo recurso en el mismo URI.

Del mismo modo, nuestra aplicación va a aceptar un PUT o POST en cualquiera de los formatos soportados (sujeto a la semántica del recurso o colección particular en cuestión.)

Answer 4

estoy de acuerdo con las otras respuestas que los recursos que le ponen no se requiere que sea el mismo que usted OBTIENE más tarde. Quería agregar algo de mi experiencia a esta pregunta en esta área.

Debe tener mucho cuidado al confiar en la negociación de contenido. Es muy complicado hacer las cosas bien y si no lo haces bien lleva a problemas desagradables para el usuario. Hagamos un ejemplo basado en imágenes ...

Si Alice PONE una imagen en un formato sin formato, entonces Bob puede OBTENER la imagen como un jpeg (a través de una transformación raw-> jpeg del lado del servidor), y Alice puede OBTENER imagen en un formato crudo; No hay problemas. Sin embargo, si Bob PONE un jpeg, entonces no hay forma de volver al formato sin formato para Alice. En el caso de las fotos de vacaciones, la falta de transformaciones simétricas puede no ser un gran problema, pero sí lo sería en las imágenes médicas.

Otra área donde la falta de transformaciones simétricas te muerde es en representaciones donde uno tiene un esquema y el otro no. En este caso, en el lado del servidor terminas haciendo convenciones sobre cómo transformarte. Pero te metes en grandes problemas cuando tratas con documentos con esquemas que cambian con el tiempo y están fuera de tu control. Cada vez que cambia el esquema, debe actualizar todas las transformaciones para la nueva forma de esquema, mientras sigue respaldando recursos utilizando el esquema anterior. La negociación de contenido se convierte rápidamente en un problema mayor que su valor, excepto en algunas circunstancias limitadas. Una de las áreas donde puede ser manejable es si usted controla completamente la representación de recursos y su esquema subyacente. Otra área es si los formatos de recursos son estándares y es posible hacer transformaciones simétricas entre los diferentes formatos.