¿Cuáles son los mejores / más comunes verbos y acciones de URL RESTful?

86

Estoy tratando de encontrar información sobre las mejores y más comunes acciones de URL RESTful.

por ejemplo, qué URL utiliza para mostrar los detalles de un elemento, para editarlo, actualizarlo, etc.

/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list   (lists the questions)

hmm. gracias a cualquiera que haya ayudado :)

rest 
— Pure.Krome
fuente

Respuestas:

173

Utilice URL para especificar sus objetos, no sus acciones:

Tenga en cuenta que lo que mencionó por primera vez no es RESTful:

/questions/show/<whatever>

En su lugar, debe usar sus URL para especificar sus objetos:

/questions/<question>

Luego, realiza una de las siguientes operaciones en ese recurso.

OBTENER:

Se utiliza para obtener un recurso, consultar una lista de recursos y también para consultar información de solo lectura sobre un recurso.

Para obtener un recurso de pregunta:

GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com

Para enumerar todos los recursos de preguntas:

GET /questions HTTP/1.1
Host: whateverblahblah.com

ENVIAR:

Se usa para crear un recurso.

Tenga en cuenta que lo siguiente es un error:

POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Si la URL aún no se ha creado, no debería utilizar POST para crearla mientras especifica el nombre. Esto debería resultar en un error de recurso no encontrado porque aún no existe. Primero debe PONER el recurso en el servidor. Podría argumentar que al crear una nueva pregunta, también está actualizando el recurso / preguntas, ya que ahora devolvería una pregunta más en su lista de preguntas.

Debería hacer algo como esto para crear un recurso usando POST:

POST /questions HTTP/1.1
Host: whateverblahblah.com

Tenga en cuenta que, en este caso, no se especifica el nombre del recurso, se le devolverá la ruta URL de los nuevos objetos.

ELIMINAR:

Se usa para eliminar el recurso.

DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com

PONER:

Se utiliza para crear un recurso o sobrescribirlo mientras especifica la URL de los recursos.

Para un nuevo recurso:

PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

Para sobrescribir un recurso existente:

PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com

... Sí, son iguales. PUT se describe a menudo como el método de 'editar', ya que al reemplazar todo el recurso con una versión ligeramente alterada, ha editado lo que los clientes OBTENERÁN la próxima vez que lo hagan.

Usando REST en formularios HTML:

La especificación HTML5 define GET y POST para el elemento de formulario .

El atributo de contenido del método es un atributo enumerado con las siguientes palabras clave y estados:

  • La palabra clave GET, que se asigna al estado GET, indica el método HTTP GET.
  • La palabra clave POST, correlacionada con el estado POST, indica el método HTTP POST.

Técnicamente, la especificación HTTP no lo limita solo a esos métodos. Usted es técnicamente libre de agregar cualquier método que desee, aunque en la práctica esto no es una buena idea. La idea es que todos sepan que usa GET para leer los datos, por lo que confundirá las cosas si decide usar READ. Dicho eso ...

PARCHE:

Este es un método que se definió en un RFC formal. Está diseñado para usarse cuando desea enviar solo una modificación parcial a un recurso, se usaría de manera similar a PUT:

PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

La diferencia es que PUT tiene que enviar todo el recurso, sin importar qué tan grande sea en comparación con lo que realmente ha cambiado, mientras que PATCH puede enviar solo los cambios.

— Brian R. Bondy
fuente
Hola Brian ... cuanto más leo esto, más sentido tiene. Supongo que algunos navegadores (o versiones de navegador) no admiten PUT o DELETE. si ese es el caso, ¿usamos POST en su lugar?
— Pure.Krome
1
Hola Pure.Knome; Los navegadores web los admiten todos, y también cualquier biblioteca HTTP debería admitirlos a todos.
— Brian R. Bondy
4
Por cierto, recomendaría comprar este libro si quieres aprender todo sobre REST oreilly.com/catalog/9780596529260
— Brian R. Bondy
1
@Brian: algunas preguntas más sobre sus ejemplos de PUT. >> PUT / questions / <new_question> ¿Por qué haría eso, en lugar de hacer >> PUT / questions / porque todos los datos del formulario se utilizarán para crear el nuevo recurso? (continúa el siguiente comentario) ...
— Pure.Krome
1
@Brian R. Bondy, Gracias por tu gran respuesta. La solicitud POST a un recurso existente se describe como "adjuntar" en el libro de descanso de oreilly (pág: 100,101), al contrario de su término general de "modificación". Después de todo, agregar es más específico que modificar, lo que puede transmitir "PUT a un recurso existente", y semánticamente suena más correcto para POST: agregar un nuevo recurso al enlace especificado, ya sea agregando o creando un recurso secundario a ese .
— Özgür
11

Suponiendo que /questions/10es una pregunta válida, entonces el método se utiliza para interactuar con ella.

POST para agregarle

PONER para crearlo o reemplazarlo

OBTENER para verlo / consultarlo

y BORRAR para bien ... eliminarlo.

La URL no cambia.

— Allain Lalonde
fuente
4
Incorrecto. PUT debe ser idempotente. Debe poder realizar la misma solicitud PUT muchas veces, sin efecto después de la primera vez. Entonces, crear un recurso con cada solicitud PUT no es idempotente.
— aehlke
3
"Los métodos PUT y DELETE se definen como idempotentes, lo que significa que varias solicitudes idénticas deben tener el mismo efecto que una sola solicitud". El uso de put en un URI que actualmente no hace que un recurso esté disponible puede crear un recurso. Poner de nuevo inmediatamente lo haría de nuevo, lo que no tendría ningún efecto. De esta manera, está creando un recurso, pero la consulta sigue siendo idempotente. Si más tarde regresa y desea cambiar el recurso, man PUT al mismo URI con diferentes datos (que sería una solicitud diferente y podría repetirse cualquier número de veces con el mismo resultado).
— Allain Lalonde
1
En realidad, eche un vistazo a la respuesta que recibió 25 votos arriba, se dice que PUT se puede usar para crear o reemplazar un recurso.
— Allain Lalonde
3
La creación solo funciona siempre que se permita especificar el ID de un nuevo recurso. Si bien es posible, es más a menudo más conveniente para el usuario publicar en / collection y recibir enlaces que incluyan la nueva identificación:
— pgraham
2
@aehIke La creación de un nuevo recurso por PUT no lo hace no idempotente, ya que la idea es que si yo 'PUT / items / 10' y el elemento 10 no existían antes, entonces simplemente se creará. Sin embargo, si vuelvo a 'PUT / items / 10' por segunda vez, bueno, ahora ya existe, por lo que simplemente se reemplazará, por lo que se conserva la idempotencia, ya que las solicitudes PUT posteriores no tienen ningún efecto secundario nuevo. (Por supuesto, suponiendo que sigo poniendo exactamente el mismo artículo cada vez)
— Alappin
3

Voy a arriesgarme y adivinar que lo que quiere decir es qué son los controladores estándar para MVC cuando dice URL "RESTful", ya que sus ejemplos podrían considerarse no "RESTful" (consulte este artículo).

Dado que Rails realmente popularizó el estilo de URL que parece interesarle, a continuación ofrezco las acciones de controlador predeterminadas producidas por ScaffoldingGenerator en Ruby on Rails. Cualquiera que utilice una aplicación Rails debería resultarle familiar.

Las acciones y vistas con scaffolding son: indexar, listar, mostrar, nuevo, crear, editar, actualizar, destruir

Normalmente, construiría esto como:

http://application.com/controller/<action>/<id>
— tvanfosson
fuente
5
Las convenciones de URI fuera de banda NO son RESTful. Citando al propio Fielding: "Una API REST no debe definir jerarquías o nombres de recursos fijos (un acoplamiento obvio de cliente y servidor). Los servidores deben tener la libertad de controlar su propio espacio de nombres. En su lugar, permitir que los servidores instruyan a los clientes sobre cómo construir URI apropiados , como se hace en formularios HTML y plantillas URI, definiendo esas instrucciones dentro de los tipos de medios y relaciones de enlace .. "
— aehlke
1

Aquí hay un mapeo de sus URL actuales utilizando el principio REST:

/question/show/<whatever>

Si identifica la pregunta como un recurso, entonces debería tener una URL única. Usar GET para mostrarlo (recuperarlo) es una práctica común. Se vuelve:

GET /question/<whatever>

/question/edit/<whatever>

Ahora desea que su usuario tenga otra vista del mismo recurso que le permita editar el recurso (tal vez con controles de formulario).

Aquí hay dos opciones, su aplicación es una aplicación (no un sitio web), entonces es mejor que use JavaScript para transformar el recurso en un recurso editable en el lado del cliente.

Si se trata de un sitio web, entonces puede usar la misma URL con información adicional para especificar otra vista, la práctica común parece ser:

GET /question/<whatever>;edit

/question/update/<whatever> (this is the post back url)

Esto es para cambiar la pregunta, por lo que PUT es el método correcto para usar:

PUT /question/<whatever>

/question/list   (lists the questions)

La lista de preguntas es en realidad el recurso principal de una pregunta, por lo que naturalmente es:

GET /question

Ahora puede que necesites más:

POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)

Tada :)

— Vincent Robert
fuente
-1

Tus cuatro ejemplos podrían ser:

GET /questions/123
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
GET /questions

Para agregar una pregunta:

POST /questions q=What+is+the+meaning+of+life

El servidor respondería:

200 OK (or 201 Created)
Location: /questions/456
— Pbreitenbach
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.