Opiniones necesarias sobre la atomicidad de un RESTful PUT

Question

Mis colegas y yo estamos implementando una serie de servicios HTTP RESTful, y estamos tratando de asegurarnos de que estamos a) siguiendo las especificaciones, yb) haciendo lo correcto " donde la especificación es corto de detalles.

Aquí es una situación particular que hemos llegado a y está buscando opiniones de la comunidad sobre: ​​

Suponga que tiene un recurso/personas/Bob, y su cliente va a actualizar con un PUT. El servidor puede generar representaciones para/People/Bob en application/json y text/html. El servidor puede interpretar representaciones para/People/Bob en application/json.

Teniendo en cuenta esta solicitud:

 
PUT /People/Bob 
Content-Type: application/json 
Accept: application/xml 

{ name: "Still Bob" } 

el servidor no puede producir una representación XML, pero puede procesar el JSON entrante. Entonces sabemos que la respuesta correcta es que el servidor devuelva el estado 406.

La pregunta es: ¿debería el servidor haber realizado la actualización a/People/Bob?

Answer 1

+1 para Filosofía del RESTO.

Sin un conocimiento detallado de la especificación HTTP, simplemente elegiría una de las opciones y documentaría el dilema y la elección.

Mi preferencia sería que el servidor no puede responder según lo solicitado, entonces no debe procesar ninguna solicitud.

Pero eso puede no funcionar en algunos escenarios, por lo que es posible que deba hacer lo contrario.

Answer 2

Yo discutiría 'sí' en teoría, pero 'no' para la aplicación en el mundo real.

Veo la lógica de no procesar si hay un error. Como devuelve un 406, no un 500, sabría que no es un error en los datos que proporcioné, sino más bien en la forma en que se me presenta el resultado.

Dicho esto, algunas aplicaciones no verifican los códigos de error; simplemente verán que regresó con un error en lugar del XML que solicitó, y supondrán que la transacción falló.

Supongo que no maneja la aplicación/xml no es un problema real, pero para los fines de la pregunta, si esto realmente se implementa como un servicio real, casi seguramente querría poder tener una representación XML, ya que es (sospecho) la interacción RESTful más común, y muchos llamadores probablemente estarían codificados para usar XML.

En resumen: si en realidad no proporciona la aplicación/xml, entonces diría que no realice la actualización. Si va a manejar todas las normas, pero usted está planeando para la contingencia de que un usuario le preguntará para la aplicación/fooSomethingNonStandard, y luego seguir adelante y llevar a cabo la actualización, pero asegúrese de responder con un 406.

Answer 3

La pregunta es: ¿debería el servidor haber realizado la actualización a/People/Bob?

De the HTTP spec, a 406 medios:

el recurso identificado por la solicitud es únicamente capaz de generar entidades de respuesta que tienen características de contenido no aceptable de acuerdo con las cabeceras aceptar enviados en la solicitud.

A menos que fuera una solicitud HEAD, la respuesta DEBERÍA incluir una entidad que contenga una lista de características de entidad disponibles y ubicación (s) de la cual el usuario o agente de usuario puede elegir la más apropiada. El formato de entidad se especifica mediante el tipo de medio proporcionado en el campo de encabezado Content-Type. Según el formato y las capacidades del agente de usuario, la selección de la opción más adecuada PUEDE realizarse automáticamente. Sin embargo, esta especificación no define ningún estándar para dicha selección automática.

Note: HTTP/1.1 servers are allowed to return responses which are 
    not acceptable according to the accept headers sent in the 
    request. In some cases, this may even be preferable to sending a 
    406 response. User agents are encouraged to inspect the headers of 
    an incoming response to determine if it is acceptable. 

Si la respuesta podría ser inaceptable, un agente de usuario debe suspender temporalmente la recepción de más datos y solicitar al usuario una decisión sobre nuevas medidas.

Esa nota en el medio acerca de HTTP/1.1 puede ser su respuesta. Lo leí diciendo "puede devolver un 200 en respuesta a la solicitud PUT a/People/Bob cuando el agente de usuario especifica application/xml en el encabezado Accept, seleccionando cualquier tipo de contenido adecuado, y que este resultado puede ser preferible a regresando 406. "

Bajo este escenario, el PUT tendría éxito en el servidor, devolvería 200, pero el cliente obtendría una representación de aplicación/json. El cliente debe ser capaz de manejar esa posibilidad asegurándose de que entiende el tipo de medio dado en el encabezado de tipo de contenido, y comportarse de una manera bien definida si no lo hace.

Pero esto siempre es cierto de todos modos.

Una cosa más: es posible que desee considerar no utilizar tipos de medios simple-vainilla como application/xml y application/json, sino definir sus propios tipos de medios personalizados, tal vez basados ​​en XHTML o JSON. Todo el client-server coupling in a RESTful application ocurre a través de los tipos de medios. Sin tipos de medios lo suficientemente ricos como para capturar los conceptos de su dominio, está especificando de manera incompleta su API REST.

Answer 4

Una forma de salir de su enigma es tener un PUT exitoso devolver un 204 (Sin contenido). De esta forma, el encabezado Accept del cliente es irrelevante para la cuestión de si se realiza la actualización.

Un cliente "RESTful" (o al menos "HTTP-abrazo") sabrá que no debe actualizar su "página" actual, y que tendrá que hacer un GET para actualizar su vista del PUT recurso. El encabezado Accept en ese GET ahora es, por supuesto, una preocupación separada de la atomicidad de la actualización.

Answer 5

Yo tendría éxito y devolvería un 200 usando el método que Rich sugiere arriba o un 406 y falla. El protocolo no permite un enfoque más matizado al mezclar 2xx (Success) con códigos 4xx (Error), por lo que 4xx se puede leer para implicar NO éxito.