Lo RESTO PUT / POST / borrar llamadas deben regresar por una convención?

Question

1. De acuerdo con la "ideología RESTO" lo que debería ser en el cuerpo de la respuesta de un PUT / POST / solicitudes DELETE?

2. ¿Qué hay de los códigos de retorno? Es suficiente HTTP_OK?

3. ¿Cuál es la razón de estos convenios, en su caso?

He encontrado un puesto buena descripción de la POST / PUT diferencias: poner vs PUT Pero todavía no responde a mi pregunta.

Answer 1

Perdona la falta de seriedad, pero si usted está haciendo a través de HTTP REST entonces RFC7231 describe exactamente qué comportamiento se espera de GET, PUT, POST y DELETE.

Actualizar (jul 3 '14):
La especificación HTTP intencionadamente no define lo que se devuelve desde POST o DELETE. La especificación sólo define lo que debe ser definido. El resto se deja hasta el implementador para elegir.

Answer 2

En general, las convenciones son “piensa que estás solo entregar páginas web”.

Para un PUT, me gustaría volver al mismo punto de vista que se obtendría si se hizo un GET inmediatamente después; que resultaría en un 200 (así, suponiendo que la representación tiene éxito por supuesto). Para un empleo, me gustaría hacer una redirección al recurso creado (asumiendo que usted está haciendo una operación de creación, si no, simplemente devolver los resultados); el código de crear con éxito es un 201, que es realmente el único código HTTP para una redirección que no está en el rango de 300.

Nunca he sido feliz por lo que un DELETE deben regresar (mi código produce actualmente un HTTP 204 y un cuerpo vacío en este caso).

Answer 3

Creación de un recurso se asigna generalmente a POST, y que debería devolver la ubicación del nuevo recurso; por ejemplo, en unos carriles de andamio un CREATE redirigirá a la demostración para el recurso recién creado. El mismo enfoque podría tener sentido para la actualización (PUT), pero eso es menos de una convención; una necesidad actualización sólo indican el éxito. Un borrado, probablemente, sólo tiene que indicar el éxito, así; si desea redirigir, de devolver la lista de los recursos probablemente tiene más sentido.

El éxito puede ser indicado por HTTP_OK, sí.

La regla sólo es rápido y duro en lo que he dicho anteriormente es que una cree debería devolver la ubicación del nuevo recurso. Esto parece una obviedad para mí; tiene todo el sentido de que el cliente tendrá que ser capaz de acceder al nuevo elemento.

Answer 4

Por el RFC7231 no importa y puede estar vacía

¿Cómo ponemos en práctica JSON solución basada norma API en el proyecto:

poste / puesto: Objeto de salidas como en los atributos get (filtro de campo / relaciones aplica la misma)

Borrar: datos sólo contiene nulo (por su representación de un objeto que falta)

Estado para el estándar de eliminación: 200