SoapUI RESTful - Métodos HTTP
Los métodos HTTP más utilizados son POST, GET, PUT, PATCH y DELETE. Estos corresponden a operaciones de creación, lectura, actualización y eliminación (o CRUD), respectivamente. También hay varios otros métodos, sin embargo, se utilizan con menos frecuencia. Entre estos métodos, OPTIONS y HEAD se utilizan con más frecuencia que otros.
ENVIAR
El método POST se utiliza para crear nuevos recursos. Se utiliza para crear recursos subordinados. Es decir, subordinado a algún otro recurso (por ejemplo, padre).
En otras palabras, al crear un nuevo recurso, POST al padre y el servicio se encarga de asociar el nuevo recurso con el padre, asignar un ID (nuevo URI de recurso), etc.
En la creación exitosa, devuelva el estado HTTP 201, devolviendo un encabezado de ubicación con un enlace al recurso recién creado con los estados HTTP 201.
POST no es seguro ni idempotente. Por lo tanto, se recomienda para solicitudes de recursos no idempotentes.
Hacer dos solicitudes POST idénticas dará como resultado dos recursos que contienen la misma información. A veces, arroja un mensaje de error según el tipo de servicios definidos.
OBTENER
El método HTTP GET se utiliza para leer o recuperar una representación de un recurso. En una respuesta exitosa, GET devuelve una representación en XML o JSON y un código de respuesta HTTP de 200 (OK). En caso de error, la mayoría de las veces devuelve un 404 (NO ENCONTRADO) o 400 (PETICIÓN MALA).
De acuerdo con el diseño de la especificación HTTP, las solicitudes GET (junto con HEAD) se utilizan solo para leer datos y no cambiarlos. Por lo tanto, GET se considera seguro.
Se puede llamar a GET sin riesgo de modificación o corrupción de datos: llamarlo una vez tiene el mismo efecto que llamarlo 10 veces. Además, GET es idempotente, lo que significa que realizar varias solicitudes idénticas conduce a obtener el mismo resultado que una sola solicitud.
Se recomienda no exponer operaciones inseguras a través de GET; nunca debe modificar ningún recurso en el servidor.
PONER
PUT se utiliza para actualizar los recursos existentes. PUT se usa como un URI de recurso conocido con el cuerpo de la solicitud que contiene la representación actualizada del recurso original.
PUT también se puede utilizar para crear un recurso en el que el cliente elige el ID del recurso en lugar de hacerlo el servidor. En otras palabras, si PUT se usa como un URI que contiene el valor de un ID de recurso inexistente.
POST se utiliza para crear nuevos recursos y proporcionar el ID definido por el cliente en la representación del cuerpo. En una actualización exitosa, devuelve 200 (o 204 si no devuelve ningún contenido en el cuerpo) de un PUT.
Si se utiliza PUT para la creación, devuelve el estado HTTP 201 cuando se crea correctamente. Un cuerpo en la respuesta es opcional.
PUT no es una operación segura, ya que modifica (o crea) el estado en el servidor, sin embargo es idempotente. Si el usuario crea o actualiza un recurso mediante PUT y luego vuelve a realizar la misma llamada, el recurso sigue ahí y tiene el mismo estado que tenía con la primera llamada.
Se recomienda mantener las solicitudes PUT idempotentes. Se recomienda encarecidamente utilizar POST para solicitudes no idempotentes.
PARCHE
PATCH se utiliza para modificar capacidades. La solicitud PATCH solo necesita contener los cambios en el recurso, no el recurso completo. Se parece a PUT, pero el cuerpo contiene un conjunto de instrucciones que describen cómo se debe modificar un recurso que reside actualmente en el servidor para producir una nueva versión.
Esto significa que el cuerpo de PATCH no debe ser solo una parte modificada del recurso, sino que debe estar en algún tipo de lenguaje de parche como JSON Patch o XML Patch.
PATCH no es seguro ni idempotente. Una solicitud de PATCH se puede emitir de tal manera que sea idempotente, lo que también ayuda a prevenir malos resultados de colisiones entre dos solicitudes de PATCH en el mismo recurso en un período de tiempo similar.
Las colisiones de múltiples solicitudes de PATCH pueden ser más peligrosas que las colisiones PUT, ya que algunos formatos de parche necesitan operar desde un punto base conocido o de lo contrario dañarán el recurso.
Los clientes que utilizan este tipo de aplicación de parche deben utilizar una solicitud condicional de modo que la solicitud falle, si el recurso se ha actualizado, desde la última vez que el cliente accedió al recurso.
ELIMINAR
DELETE se utiliza para eliminar un recurso identificado por un URI. Tras una eliminación exitosa, devuelve el estado HTTP 200 (OK) junto con un cuerpo de respuesta, la representación del elemento eliminado. De lo contrario, devuelve el estado HTTP 204 (SIN CONTENIDO) sin cuerpo de respuesta.
En otras palabras, un estado 204 sin cuerpo, o la respuesta estilo JSEND y el estado HTTP 200 son las respuestas recomendadas.
En cuanto a las especificaciones HTTP, las operaciones DELETE son idempotentes. Si el usuario elimina un recurso, se elimina. Llamar repetidamente a DELETE en el mismo recurso termina con el mismo resultado: el recurso se ha ido.
Llamar a DELETE en un recurso por segunda vez a menudo devolverá un 404 (NO ENCONTRADO), ya que ya se eliminó y, por lo tanto, ya no se puede encontrar. Esto hace que las operaciones DELETE ya no sean idempotentes, sin embargo, el estado final del recurso es el mismo. Devolver un 404 es aceptable y se comunica con precisión con el estado de la llamada.