Servicios REST: exposición de "acciones" que no son datos

Entiendo cómo usar REST para realizar interacciones de entidades generales, usando nombres de URL para mapear entidades y verbos HTTP para mapear acciones en esas entidades. Pero, ¿cuál es la forma generalmente aceptada de ver las "acciones" más como RPC?Servicios REST: exposición de "acciones" que no son datos

Por ejemplo, supongamos que quiero enviar un comando para que el dispositivo se reinicie? No hay una "entidad" real aquí o hago algo así como POST a http://mydevice/device/reset?

Fuente

2010-03-15 ctacke

/device/reset o /system/reset están bien.

El "patrón de diseño" RESTO no animarle a no utilizar ningún verbos .. Se podría hacer:

POST http://mydevice/system/state  
<stateType>RESET</stateType>

Información relacionada:

How to create REST URL’s without verbs?
Hilos etiquetados con restful-url

Fuente

2010-03-15 14:19:56

Sí, esa es una posible solución. –

Normalmente llamo a la entidad "sistema" o algo así. Entonces haces "/ system/reset". Has elegido el dispositivo para que también funcione.

Pero sí, generalmente considero que estos tipos de acciones son actualizaciones, que usarían el método POST. Así que creo que está en lo correcto al POST/dispositivo/restablecer

Fuente

2010-03-15 14:17:04 Seaux

Es curioso que tengas que introducir la palabra PUT/POST; también te pregunté sobre eso: http://stackoverflow.com/questions/2447677/rest-verbs-which-convention-is-correct/2447714#2447714 – ctacke

Voy a comentar sobre eso, pero también uso una variación REST ya que no todos los clientes manejan PUT/DELETE. Lea la página de wikipedia para REST: http://en.wikipedia.org/wiki/Representational_State_Transfer – Seaux

Sí, leí el artículo de Wikipedia. Como estoy controlando tanto el servicio como el cliente, tengo el lujo de usar los 4 verbos. – ctacke

No creo que sea el caso para usar POST. La "acción RESTABLECER" es una acción idempotente (si la llamas n veces, siempre obtendrás el mismo resultado), así que en mi humilde opinión debes utilizar una llamada PUT en lugar de POST (ya que POST no es idempotente).

También, como usted está poniendo un recurso, puede utilizar

PUT http://system 
<device> 
    <status>RESET</status> 
</device>

PUT http://system/status/reset

pero creo que la primera es "más tranquilo", ya que se está poniendo un recurso, mientras que el segundo solo usa la url.

Fuente

2010-03-15 14:30:48

por lo que diría que PUT es una ACTUALIZACIÓN y POST es un INSERT (IBM en lugar de la definición de Sun)? Vea esto: http://stackoverflow.com/questions/2447677/rest-verbs-which-convention-is-correct/2447740#2447740 – ctacke

Not Really. Si piensa en CRUD, puede usar esta analogía, y es correcto decir que si tiene INSERT y UPDATE, debe usar POST y PUT, respectivamente. Pero la idempotencia es más que eso. Imagine que hay un recurso que solo puede insertar una vez en su base de datos y nunca debe cambiarlo. Es un inserto y una acción idempotente, por lo que en esta situación, creo que se usará PUT. –

PUT http: // system/status/reset con un cuerpo vacío solo actualiza el recurso para que esté vacío. El primero es el camino RESTful correcto. –

Servicios REST: exposición de "acciones" que no son datos

Respuesta

Cuestiones relacionadas