[APORTE] Entendiendo las cabeceras (POST, GET, PUT, DELETE)

[abimaelrc]

Saludos,

Leyendo artículos por internet me encontré con este http://jcalcote.wordpress.com/2008/1...-of-the-story/ que me motivo a seguir leyendo y entre uno de sus artículos de referencia estuve leyendo este http://www.artima.com/lejava/article...nd_delete.html muy útil para entender sobre porque existe put y delete en las cabeceras. Los que no dominen el ingles les recomiendo que usen un traductor.

Cualquier duda indiquenselo al autor de los artículo Son bromas, las pueden hacer aquí...

[abimaelrc]

Bueno, para facilitar algunos que puede no le interesen porque el contenido está en ingles (que no debería ser un impedimento para aprender ), les dejo la interpretación y la definición de las palabras que usan

Iniciado por http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/

Diseñadores de servicios Web han tratado desde hace algún tiempo correlacionar CRUD (Crear, recuperar, actualizar y eliminar) la semántica con "Representational State Transfer" (REST) unos verbos definidos por la especificación de HTTP: GET, PUT, POST, DELETE, HEAD, etc.

Muy a menudo, los desarrolladores tratan de correlacionar estos dos conceptos: CRUD y REST mediante una asignación de uno a uno de los verbos:

• Crear = PUT
• Leer = GET
• Actualizar = POST
• Borrar = DELETE

Pero tal asignación trivial es inexacta, en el mejor de los casos. La semántica de estos verbos no tienen relación directa. Esto no quiere decir que no se puede crear un cliente CRUD que puede hablar con un servicio REST. Más bien, es necesario añadir un poco de lógica adicional de nivel superior a la asignación para completar la transformación de un espacio a otro.

Mientras que recuperar realmente se asigna a una solicitud GET HTTP, y también eliminar realmente se asigna a una operación HTTP DELETE, el mismo no puede decirse de crear y PUT o la actualización y POST. En algunos casos, crear es PUT, pero en otros casos se debe emplear POST. Del mismo modo, en algunos casos, actualización puede ser POST, mientras que en otros PUT.

La esencia de la cuestión se reduce a un concepto conocido como *idempotencia. Una operación es idempotente si hay una secuencia de dos o más del mismo resultado de operación en el mismo estado de recurso, al igual que se trabaja con una clase que implementa singleton. De acuerdo con la especificación HTTP 1.1, GET, HEAD, PUT y DELETE son idempotentes, mientras que POST no lo es. Es decir, una secuencia de varios intentos de poner los datos a una URL se traducirá en el estado de los recursos lo mismo que un solo intento de poner los datos a esa URL, pero el mismo no se puede decir de una petición POST. Por ello, un navegador siempre le aparece un cuadro de diálogo de advertencia cuando se hace más de una petición en un formulario POST.

Después de ese debate, una asignación más realista parece ser:

• Crear = PUT si y sólo si va a enviar todo el contenido del recurso especificado (dirección URL)
• Crear = POST si va a enviar un comando al servidor para crear un subordinado del recurso especificado mediante algún algoritmo del lado del servidor
• Recuperar = GET
• Actualizar = PUT si y sólo si va a actualizar el contenido completo del recurso especificado
• Actualizar = POST si usted está solicitando el servidor para actualizar uno o más subordinados del recurso especificado
• Eliminar = DELETE

... Lo demás son ejemplos...

* idempotente = Se refiere a una operación que produce los mismos resultados sin importar cuántas veces se lleva a cabo. Por ejemplo, si una solicitud para eliminar un archivo se completa con éxito de un programa, todas las solicitudes posteriores a eliminar ese archivo de otros programas devolverán el mensaje de confirmación del primero como éxito si la función de borrado es idempotente. En una función que no es idempotente, un error se devuelve para la segunda y subsiguientes peticiones que indica que el archivo no estaba allí, y que la condición de error puede provocar que el programa se detuviera. Si todo lo que se desea es garantizar un determinado archivo se ha eliminado, una función idempotente de eliminar devolvería el resultado mismo, éxito, no importa cuántas veces se ha ejecutado para el mismo archivo.

En todo esto se refiere a cuando por ejemplo, tenemos un formulario y ese formulario no vemos que haya una acción, continuamos presionando varias veces el botón de "submit" hasta que vemos resultado. Eso lo evitamos verificando la misma solucitud que se sometió consultando si ya existe el resultado en la base de datos. O cuando refrescamos la pantalla y si usamos POST vemos el cuadro de advertencia de que si desea enviar los datos nuevamente, mientras que PUT no aparece, sino que te muestra el resultado de la primera vez.

[pateketrueke]

Afortunadamente esta pensando en el modelo RESTful cuando de repente noté tu tema abimaelrc, creo que ya no es necesario seguir investigando.

Las referencias que pones son bastante buenas, de hecho creo que ya no tengo ninguna duda al respecto de como implementar dichas interfaces usando headers.

Excelente.