REST: cómo gestionaría una solicitud PUT los identificadores de recursos de incremento automático

Question

Según HTTP 1.1. especificaciones:

Si el Request-URI no apunta a un recurso existente, y que URI es capaz de ser definido como un nuevo recurso por el agente usuario solicitante, el servidor de origen puede crear el recurso con el que se URI.

En otras palabras, PUT se puede utilizar para crear la actualización &. Más específicamente, si hago una solicitud PUT, p.

PUT /users/1 

y que el usuario no existe, yo esperaría que el resultado de esta solicitud para crear un usuario con este ID. Sin embargo, ¿cómo funcionaría esto si tu back-end está usando una clave de autoincremento? ¿Sería un caso de simplemente ignorarlo si no es factible (por ejemplo, el incremento automático es a las 6 y solicito 10) & creando si es posible (por ejemplo, solicitud 7)?

Desde el fragmento que he extractado arriba, parece que le da esta flexibilidad, solo en busca de alguna aclaración.

Answer 1

Le sugiero que use POST, no PUT, para una tecla de incremento automático, o no use la tecla de incremento automático en la ID del recurso.

Si usa POST, entonces POSTARÍA a /users en lugar de a /users/1. La respuesta puede redirigirlo al /users/1 o cualquiera que sea la ID.

Si usa PUT, entonces PUEDE PONER en /users/10292829 donde el número es una clave de recurso única generada en el cliente. Esta clave puede ser generada por tiempo, o puede ser una combinación de tiempo, ID de sesión y otros factores para garantizar la exclusividad del valor en la audiencia de su cliente. El servidor puede generar su propio índice autoincrementado, distinto de 10292829 o lo que sea.

Para más información sobre esto, ver PUT vs POST in REST

---

seguimiento. . .

En el caso de permitir PUT a/users/XXXXXXX, para todos los usuarios, terminaría con dos claves únicas distintas que hacen referencia al mismo recurso. (10292829 y 1 pueden referirse al mismo usuario). Debería decidir cómo permitir el uso de cada una de estas claves diferentes en una URL de estilo REST. Debido a la necesidad de conciliar el uso de estos dos identificadores distintos, preferiría usar la primera opción, POSTING al /users y obtener una url REST exclusiva del recurso creado en la respuesta.

acabo de releer the relevant section of RFC 2616, y vi un código de retorno diseñado específicamente para esto en aplicaciones REST:

10.2.2 201 Creado

La solicitud se ha cumplido, y dio lugar a un nuevo recurso siendo creado. Los URI (s) devueltos en la entidad de la respuesta pueden hacer referencia al recurso recién creado, con el URI más específico para el recurso dado por un campo de encabezado de ubicación. La respuesta DEBERÍA incluir una entidad que contenga una lista de características del recurso y ubicación (es) a partir de la cual el usuario o agente del 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.El servidor de origen DEBE crear el recurso antes de devolver el código de estado 201. Si la acción no se puede llevar a cabo de inmediato, el servidor DEBE responder con una respuesta 202 (Aceptado) en su lugar.

Por lo tanto, la forma en REST para ir es para publicar en /users y devolver una 201 Created, con una cabecera que especifica Location:/users/1.

Answer 2

Debe utilizar POST para crear recursos, mientras que el PUT solo debe utilizarse para la actualización. En realidad, la semántica de REST te obliga a hacerlo.