¿Manera RESTful adecuada para manejar una solicitud que realmente no está creando u obteniendo algo?

Question

Estoy escribiendo una pequeña aplicación que solo hace una cosa: toma algunos datos proporcionados por el usuario, hace algunos análisis y devuelve una "etiqueta" para esos datos. Estoy pensando que el cliente debe GET o POST su solicitud al /getTag para obtener una respuesta.

No se almacena nada en el servidor cuando el cliente hace esto, por lo que se siente raro usar un POST. Sin embargo, tampoco hay un URI uniforme para el análisis, por lo que usar un GET parece extraño, ya que devolverá diferentes cosas dependiendo de qué datos se proporcionen.

¿Cuál es la mejor manera de representar esta funcionalidad con REST?

Answer 1

POST puede representar la realización de una acción. La acción no es tiene como una acción de base de datos.

Lo que realmente ha creado es un procedimiento remoto. RPC generalmente es todo POST. No creo que esto sea una buena opción para REST, pero eso no tiene por qué impedir el uso de URL simples y JSON.

Answer 2

La "mejor manera" es hacer lo que sea más apropiado para su aplicación y sus necesidades. Sin saber que, aquí están algunas ideas:

1. GET es el verbo más apropiado, ya que no va a crear o almacenar nada en el servidor, simplemente recuperar algo que el servidor proporciona.

2. No coloque la palabra get en el URI como ha sugerido. Los verbos como ese ya están provistos por HTTP, así que simplemente use /tag y GET en su lugar.

3. Debe utilizar un URI bien entendido (o "bueno") para este recurso y pasar los datos como parámetros de consulta. No me preocuparía que se sienta raro (ver this question's respuestas para averiguar por qué).

En resumen, simplemente GET en /tag?foo=bar&beef=dead, y ya está.

Answer 3

Me parece que probablemente haya una razón por la cual usted o el usuario que generó los datos originales querrían que la etiqueta generada persistiera, ¿verdad?

Si eso es una posibilidad, entonces lo escribiría como POST /tags y pasaría el URI de recursos /tags/:id como ubicación: encabezado.

Si realmente no me importaba persistir en la etiqueta generada, pensaría en lo que eran los "datos generados por el usuario" y cuánto está pasando el procesamiento detrás de escena. Si la "etiqueta" es lo suficientemente diferente de los datos que se pasan al sistema, GET /tag puede ser muy confuso para un consumidor API.

Answer 4

Responderé a la respuesta de Brian: use un GET. Si los mismos parámetros de entrada devuelven la misma salida, y realmente no está creando nada, es una acción idempotente y por lo tanto perfectamente adecuada para un GET.

Answer 5

Puede utilizar GET y POST ya sea:

• GET /tag?data="..." -> 200, tag

  El método GET significa recuperar cualquier información (en forma de una entidad ) se identifica por el Request-URI. Si el URI de solicitud se refiere a un proceso de producción de datos, son los datos producidos que serán devueltos como la entidad en la respuesta y no el texto de origen del proceso , a menos que ese texto sea el resultado del proceso.

• POST /tag {data: "..."} -> 200, tag

  la acción realizada por el método POST podría no resultar en un recurso que puede ser identificado por un URI. En este caso, 200 (OK) o 204 (Sin contenido) es el estado de respuesta apropiado, dependiendo de si o no, la respuesta incluye una entidad que describe el resultado.

según la method definitions sección/estándar HTTP.

Usaría GET si fuera usted (y POST solo si desea enviar archivos).