sirven - ¿Qué métodos HTTP coinciden con los métodos CRUD?

para que sirven los metodos http (9)

En la programación de estilo REST, deberíamos usar métodos HTTP como nuestros bloques de construcción. Estoy un poco confundido, sin embargo, qué métodos coinciden con los métodos clásicos de CRUD. GET / Read y DELETE / Delete son suficientemente obvios.

Sin embargo, ¿cuál es la diferencia entre PUT / POST? ¿Coinciden uno a uno con Crear y Actualizar?

Depende de la situación concreta .. pero en general:

PUT = actualizar o cambiar un recurso concreto con un URI concreto del recurso.

POST = crear un nuevo recurso bajo la fuente del URI dado.

Es decir

Editar una entrada de blog:

PUT: / blog / entry / 1

Crea uno nuevo:

POST: / blog / entrada

PUT puede crear un nuevo recurso en algunas circunstancias donde el URI del nuevo recurso está claro antes de la solicitud. POST también se puede usar para implementar otros casos de uso, que no están cubiertos por los demás (GET, PUT, DELETE, HEAD, OPTIONS)

El entendimiento general para los sistemas CRUD es GET = request, POST = create, Put = update, DELETE = delete

El proyecto Symfony intenta mantener sus métodos HTTP unidos a los métodos CRUD, y su lista los asocia de la siguiente manera:

GET Recupera el recurso del servidor
POST Crear un recurso en el servidor
PUT Actualizar el recurso en el servidor
ELIMINAR Eliminar el recurso del servidor

Vale la pena señalar que, como dicen en esa página, "en realidad, muchos navegadores modernos no admiten los métodos PUT y DELETE".

Por lo que recuerdo, Symfony "simula" PUT y DELETE para aquellos navegadores que no los admiten al generar sus formularios, para intentar estar lo más cerca posible de usar el método HTTP teóricamente correcto incluso cuando un navegador no es compatible eso.

En este momento (2016) los últimos verbos HTTP son GET, POST, PATCH , PUT y DELETE

Visión general

HTTP GET - SELECCIONAR / Solicitar
HTTP PUT - ACTUALIZACIÓN
POST HTTP - INSERTAR / Crear
PATCH DE HTTP: cuando la representación de un recurso completo es engorroso y utiliza más ancho de banda, por ejemplo: cuando tiene que actualizar parcialmente una columna
HTTP BORRAR - BORRAR

¡Espero que esto ayude!

Si está interesado en diseñar API REST, ¡esta es una lectura incómoda! sitio web versión en línea repository github

En términos generales, este es el patrón que uso:

HTTP GET - SELECCIONAR / Solicitar
HTTP PUT - ACTUALIZACIÓN
POST HTTP - INSERTAR / Crear
HTTP BORRAR - BORRAR

Estaba buscando la misma respuesta, esto es lo que dice IBM. IBM Link

POST Creates a new resource. GET Retrieves a resource. PUT Updates an existing resource. DELETE Deletes a resource.

Hay una gran charla de video de youtube por stormpath que realmente explica esto, la URL debe saltar a la parte correcta del video:

video stormpath youtube

También vale la pena verlo, es más de una hora de conversación pero es muy interesante si estás pensando en invertir tiempo en construir una API REST.

La clave completa es si estás haciendo un cambio idempotente o no. Es decir, si tomar acción en el mensaje dos veces resultará en que "la misma cosa" esté allí como si solo se hubiera hecho una vez, tiene un cambio idempotente y debe asignarse a PUT. Si no, se asigna a POST. Si nunca permite que el cliente sintetice las URL, PUT está bastante cerca de Actualizar y POST puede manejar Crear muy bien, pero ciertamente no es la única forma de hacerlo; Si el cliente sabe que quiere crear /foo/abc y sabe qué contenido colocar allí, funciona bien como un PUT.

La descripción canónica de un POST es cuando te comprometes a comprar algo: esa es una acción que nadie quiere repetir sin saberlo. Por el contrario, configurar la dirección de envío para el pedido de antemano se puede hacer con PUT bien: no importa si se le 6 Anywhere Dr, Nowhereville que envíe a 6 Anywhere Dr, Nowhereville una vez, dos veces o cien veces: sigue siendo la misma dirección. ¿Eso significa que es una actualización? Podría ser ... Todo depende de cómo quieras escribir el back-end. (Tenga en cuenta que los resultados podrían no ser idénticos: podría informar al usuario la última vez que hizo un PUT como parte de la representación del recurso, lo que garantizaría que los PUT repetidos no causen un resultado idéntico, pero el resultado aún sería ser "el mismo" en un sentido funcional.)

Los bloques de construcción de REST son principalmente los recursos (y URI) y la hipermedia. En este contexto, GET es la forma de obtener una representación del recurso (que de hecho se puede asignar a un SELECT en términos de CRUD).

Sin embargo, no necesariamente debe esperar una asignación uno a uno entre las operaciones CRUD y los verbos HTTP. La principal diferencia entre PUT y POST es sobre su propiedad idempotente. POST también se usa más comúnmente para actualizaciones parciales, ya que PUT generalmente implica el envío de una nueva representación completa del recurso.

Sugiero leer esto:

La especificación HTTP también es una referencia útil:

El método PUT solicita que la entidad adjunta se almacene bajo el URI de solicitud suministrado.
[...]
La diferencia fundamental entre las solicitudes POST y PUT se refleja en el significado diferente de la solicitud-URI. El URI en una solicitud POST identifica el recurso que manejará la entidad adjunta. Ese recurso podría ser un proceso de aceptación de datos, una puerta de enlace a algún otro protocolo o una entidad separada que acepte anotaciones. En contraste, el URI en una solicitud PUT identifica la entidad incluida en la solicitud: el agente de usuario sabe a qué se destina el URI y el servidor NO DEBE intentar aplicar la solicitud a algún otro recurso. Si el servidor desea que la solicitud se aplique a un URI diferente,

Create = PUT with a new URI POST to a base URI returning a newly created URI Read = GET Update = PUT with an existing URI Delete = DELETE

PUT se puede asignar a Crear y Actualizar, según la existencia del URI utilizado con el PUT.

POST mapas para crear.

Corrección: POST también puede asignarse a Actualizar aunque se usa normalmente para Crear. POST también puede ser una actualización parcial, por lo que no necesitamos el método de PATCH propuesto.