¿Qué verbo HTTP debo usar para desencadenar una acción en un servicio web REST?

No creo que haya un verbo correcto para esta acción porque esta transacción no es realmente "REST". La "s" y la "t" representan la "transferencia de estado" y aquí no se transfiere nada. O, dicho de otra manera, según la definición más estricta, los verbos como PUT y POST siempre se usan con un sustantivo y "recargar" solo tiene el verbo.

Es posible que esta recarga no sea REST, pero puede ser útil y solo tendrás que elegir la forma de hacerlo y vivir o explicar que es inusual. GET es probablemente el más simple. Sin embargo, hay una gran cantidad de escepticismo en los comentarios, por lo que deberías pensar si esta acción de recarga es necesaria o no, porque otra cosa no está haciendo lo que debería estar haciendo.

Si desea ser RESTful no piense en el verbo para realizar una acción, piense en el estado en el que desea que esté el recurso después de que el cliente haya hecho algo.

Entonces, utilizando uno de sus ejemplos anteriores, tiene una cola de correo electrónico que está enviando correos electrónicos. Desea que el cliente ponga esa cola de correo en el estado de pausa o parada o algo así.

Entonces el cliente PONE un nuevo estado al servidor para ese recurso. Puede ser tan simple como este JSON

PUT http://myserver.com/services/email_service HTTP/1.1
Content-Type: text/json

{"status":"paused"}

El servidor descubre cómo pasar del estado actual (diga "en ejecución") al estado / estado "pausado".

Si el cliente realiza un GET en el recurso, debería devolver el estado en el que se encuentra actualmente (diga "pausado").

La razón para hacerlo de esta manera, y la razón por la cual REST puede ser tan poderoso, es que dejas el CÓMO para llegar a ese estado en el servidor.

El cliente simplemente dice "Este es el estado en el que debería estar ahora" y el servidor se da cuenta de cómo lograrlo. Podría ser un simple giro en una base de datos. Podría requerir miles de acciones. Al cliente no le importa, y no tiene que saberlo.

Para que pueda reescribir / rediseñar completamente cómo el servidor hace eso y al cliente no le importa. El cliente solo necesita conocer los diferentes estados (y sus representaciones) de un recurso, no de ninguno de los elementos internos.

Algunas de las otras respuestas, incluida la aceptada, le recomiendan que utilice un GET (aunque no con mucho entusiasmo).

No estoy de acuerdo.

En primer lugar, todos los demás que te dicen que esto no es lo ideal y que no son realmente RESTOS son correctos. En un escenario RESTful adecuado, está manipulando recursos en el servidor y agregando, actualizando, eliminando, recuperando, etc. esos recursos. Un PUT debe enviar una carga útil que represente lo que debería ser el recurso cuando se complete la solicitud, y POST debe enviar una carga útil que represente un recurso que se agregará al servidor. Y un GET debería devolver un recurso en el servidor.

Tiene un RPC (llamada a procedimiento remoto), que no es RESTful - desea HACER algo en el servidor. Entonces, si estás tratando de crear una API puramente REST, debes reconsiderar lo que estás haciendo.

Dicho esto, a veces es necesario doblar un poco las reglas. Especialmente si está desarrollando una API interna que no va a ser expuesta al público, puede decidir que la compensación vale la pena.

Si lo haces, recomendaría un PUT o POST, dependiendo de si el RPC es idempotent o no .

En general, decimos que HTTP PUT se asigna a ACTUALIZACIÓN DE SQL y que HTTP POST se asigna a SQL INSERT, pero eso no es estrictamente cierto. Una forma más pura de afirmar es que HTTP PUT debe ser idempotente y HTTP POST no tiene por qué serlo. Esto significa que puede llamar a la misma solicitud PUT tantas veces como quiera sin efectos secundarios. Una vez que lo has llamado una vez, es inofensivo llamarlo de nuevo. Pero no debe llamar repetidamente las solicitudes POST a menos que tenga la intención de hacerlo: cada POST cambia los datos en el servidor nuevamente.

En su caso, si necesita tener esta función de recarga, recomendaría un PUT porque suena como si fuera idempotente. Pero aún así le insto a que considere lo que los otros dijeron sobre no necesitarlo en absoluto.

POST y PUT son los verbos HTTP utilizados para enviar una entidad a un servidor web. Con PUT , la entidad enviada es la representación (nueva) para el recurso en el URI dado, que no se ajusta a lo que desea. POST es para el manejador de formularios tradicional, donde la entidad son datos auxiliares para el recurso, así que ese es el ganador. La entidad incluiría el comando o la acción (por ejemplo, "acción = recargar").

Dicho esto, el comando en cuestión probablemente no debería exponerse a través de una interfaz REST. Parece que la necesidad de "recargar" surge porque los datos se pueden cambiar a través de algún otro canal (por ejemplo, sistema de archivos, cliente DB). Los cachés deben ser transparentes. Además, las solicitudes HTTP deben ser atómicas, incluso teniendo en cuenta los mensajes enviados a través de otros canales. Ofrecer un comando de "recarga" para los ajustes de configuración parece una complejidad innecesaria; Requerirlo es un diseño quebradizo. Exponer "recargar" para limpiar después de una actualización a través de otro canal está sucio porque un canal no contiene toda la conversación. En su lugar, considere uno de:

• realizar actualizaciones completamente a través de REST
• exponiendo el (los) comando (s) al otro canal
• automatizando las acciones

Es posible que algunas de esas opciones no sean viables, dependiendo de qué otras restricciones existen.

Consulte también " PUT vs POST en REST ".

Argumentaría por qué una solicitud de cliente tendría que hacer explícitamente una llamada para actualizar algo así. Suena como que debería ser una lógica oculta en una implementación más típica de GET (es decir, datos de extracción, pero el servicio realiza una actualización de los datos antes de que se extraiga), o por otro disparador en el backend fuera del cliente.

Después de todo, los datos / configuración solo tendrían que estar actualizados en las llamadas subsiguientes, por lo que me inclino más hacia una llamada perezosa y ansiosa para una actualización de datos. Obviamente estoy asumiendo mucho aquí, pero daría un paso atrás para reevaluar la necesidad de una llamada tan explícita e independiente.

Por qué no tratar la acción como un recurso. Por lo tanto, como desea actualizar el caché, POSTARÁ una nueva acción en su sistema.

Para los puristas, podrías tener una URL dedicada para eso. Tenga en cuenta que podría extender esto y registrar las acciones reales en una base de datos (o en cualquier almacenamiento) con fecha, estado, usuario, etc. Solo mis pensamientos aquí.

Operación genérica en todo el sistema / acciones / {acción}

Operación específica para un tipo de recurso / actions / {resource} / {action}

Operación específica de un recurso / actions / {resource} / {id} / {action}

En su caso, la memoria caché es probablemente de todo el sistema / actions / reload_cache

Este no es un caso de uso de libro de texto, pero si quiere ser compatible en teoría, use PUT, que se supone que actualiza los datos. Aunque no tienes carga útil. Un simple GET no sería tan malo en este caso.

Los verbos HTTP no tienen nada que ver con REST.

Puede preguntar qué sería el VERB convencional para realizar alguna acción, pero aún así, no tiene nada que ver con REST.

REST es un estilo arquitectónico, que trata principalmente de cómo los componentes se comunican entre sí. Define un conjunto de principios, no un conjunto de Protocolos o Verbos.

Puede crear nuevos recursos con el verbo BORRAR, si bien no tiene ningún sentido y no es convencional, aún puede ser completamente RESTFul, siempre que se cumplan las restricciones.

En cuanto a su pregunta, no es el verbo, la URL, el formato del mensaje lo que determina si es REST o no, sino la semántica de la definición de la API de su servicio y el protocolo subyacente. ¿La operación de "recarga" rompe alguna de las restricciones de REST? Me parece que no lo hace, por lo que puede usar cualquier VERBO que desee, no hará que su servicio resulte más o menos RESTAURANTE.

En cuanto a su caso de uso, usaría el verbo GET. Simplemente porque no hay un VERBO HTTP para tal acción, y en estos casos uso el verbo GET, solo porque uso HTTP y tengo que usar un VERBO.

Encuentro todas las respuestas muy interesantes y perspicaces. Sin embargo, para la pregunta original hay una respuesta clara para mí, que no se siente incómodo: Comprender 'recargar' no como una acción, sino como una señal. Y una señal es un recurso. Entonces, en una API de estilo REST sería POST / reloadSignal.

Y la publicación de esta señal activa la acción apropiada. Desde una perspectiva REST, no creo que sea un problema no almacenar estas señales (si no es necesario por razones comerciales).