una - ¿Cuáles son los mejores/comunes verbos de URL RESTful y acciones?
rest api tutorial español (5)
Aquí hay un mapeo de sus URL actuales usando el principio REST:
/question/show/<whatever>
Si identifica la pregunta como un recurso, entonces debe tener una URL única. Usar GET para mostrarlo (recuperarlo) es la 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 permite 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 puede que sea mejor usar JavaScript para transformar el recurso en un recurso editable desde el lado del cliente.
Si se trata de un sitio web, puede utilizar 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 necesitar un poco más:
POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)
Tada :)
Estoy tratando de encontrar algo de información sobre las mejores y más comunes acciones de URL RESTful.
por ejemplo, qué url usas para mostrar los detalles de un artículo, 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 ayudando :)
Asumir /questions/10 es una pregunta válida, entonces el método se usa para interactuar con ella.
POST para agregarlo
PUT para crearlo o reemplazarlo
GET para verlo / consultarlo
y BORRAR bien ... eliminarlo.
La url no cambia.
Sus 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
Voy a dar un paso en falso y supongo que lo que quieres decir es cuáles son los controladores estándar para MVC cuando dices URL "RESTful", ya que tus ejemplos podrían considerarse no "RESTful" (mira this artículo).
Como Rails realmente popularizó el estilo de URL que pareces estar interesado, ofrezco debajo de las acciones predeterminadas del controlador producidas por ScaffoldingGenerator en Ruby on Rails. Estos deberían ser familiares para cualquiera que use una aplicación de Rails.
Las acciones y vistas con scaffolded son: index, list, show, new, create, edit, update, destroy
Normalmente, construirías esto como:
http://application.com/controller/<action>/<id>
Use las 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>
A continuación, realice una de las operaciones siguientes en ese recurso.
OBTENER:
Se usa para obtener un recurso, consultar una lista de recursos y también para consultar información de solo lectura en 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:
Usado para crear un recurso.
Tenga en cuenta que el siguiente es un error:
POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com
Si la URL aún no se ha creado, no debe usar POST para crearla mientras especifica el nombre. Esto debería dar como resultado un error de recurso no encontrado porque todavía 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á 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 el nombre del recurso no se especifica, la nueva ruta URL de los objetos le será devuelta.
BORRAR:
Usado para borrar el recurso.
DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com
PONER:
Se usa para crear un recurso, o sobrescribirlo, mientras se 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 lo mismo. PUT a menudo se describe como el método de "edición", ya que al reemplazar todo el recurso con una versión ligeramente alterada, ha editado lo que los clientes obtendrán cuando vuelvan a hacerlo.
Uso de REST en formularios HTML:
La especificación HTML5 define GET y POST para el elemento de formulario .
El atributo de contenido de método es un atributo enumerado con las siguientes palabras clave y estados:
- La palabra clave GET, mapeo al estado GET, que indica el método HTTP GET.
- La palabra clave POST, mapeo al estado POST, que indica el método HTTP POST.
Técnicamente, la especificación HTTP no te limita solo a esos métodos. Usted es técnicamente libre de agregar los métodos que desee, pero en la práctica, esta no es una buena idea. La idea es que todos sepan que usa GET para leer los datos, por lo que confundirá la cuestión si decide usar READ en su lugar. Eso dijo ...
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 cuán grande sea en comparación con lo que realmente ha cambiado, mientras que PATCH puede enviar solo los cambios.