Strange Patterns: HTTP Codes - Arquitectura Restful

24 November 2017

HTTP Codes - Arquitectura Restful

La arquitectura Rest se basa fuertemente en el protocolo HTTP, por lo cual es importante responder (y parsear al recibir) los diferentes códigos HTTP que existen.
Los códigos están agrupados por las siguientes categorías:

1xx – Informational

2xx – Successful

3xx – Redirection

4xx - Client Error

5xx - Server Error

El proyecto deberia uso granular de estos códigos con alguna libreria transversal.

Deberíamos usar solo los códigos más útiles (top “10”) que son los siguientes:

HTTP Response codes

200	OK	Successfully executed. should be used to indicate nonspecific success
201	CREATED	Successfully executed and a new resources has been created. The response body is either empty or contains a URI(s) of the created resource. The location header should should also contain the new URI
202	ACCEPTED	The request was valid and has been accepted but has not yet been processed. The response should include a URI to poll for status updates on the request. Allows for asynchronous request ( start of an asynchronous action)
204	NO_CONTENT	The request was successful but the server did not have a response. should be used when the response body is intentionally empty. Ejemplo: Si se busca el listado de productos para un cliente y el cliente existe pero la lista es vacía, el estado es 204
301	MOVED_PERMANENTLY	The new location should be returned in the response ( should be used to relocate resources)
302	REDIRECT	The HTTP response status code 302 Found is a common way of performing URL redirection.
400	BAD_REQUEST	Malformed or invalid request
401	UNAUTHORIZED	Invalid authorization credentials. (no autenticado, o autenticado incorrectamente)
403	FORBIDDEN	Disallowed request. Security error. (no autorizado para ver pagina/recurso)
404	NOT_FOUND	Resource not found. Ejemplo: Si se busca un cliente por rut y éste no existe, el estado es 404
405	METHOD_NOT_ALLOWED	Method (verb) not allowed for requested resource. Response will provide an “Allow” header to indicate what is allowed
412	PRECONDITION_FAILED	One or more conditions given in the request header fields evaluated to false when tested on the server.
415	UNSUPPORTED_MEDIA_TYPE	Client submitted a media type that is incompatible for the specified resource.
422	UNPROCESSABLE_ENTITY	Se ha producido un error funcional. El servicio reconoce los parámetros como válidos, pero alguna condición de negocio no se puede llevar a cabo. Ej: "Monto Pagado+monto capitalizado no puede ser mas que monto adeudado+monto vencido+monto adeudado ajuste-monto condonado para monto XXX" invocando a servicio bus para cálculo de pago.
418	I'm a teapot	Ludic HTTP
500	INTERNAL_SERVER_ERROR	Catchall for server processing problem
503	SERVICE_UNAVAILABLE	Response in the face of too many request
504	GATEWAY_TIMEOUT	server error response code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server that it needed in order to complete the request.

HTTP verbs:

GET. The GET method requests a representation of the specified resource. Requests using GET should only retrieve data. (idempotent)
POST. The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server (payload)
HEAD. The HEAD method asks for a response identical to that of a GET request, but without the response body.
PUT. The PUT method replaces all current representations of the target resource with the request payload.
DELETE. The DELETE method deletes the specified resource.
CONNECT. The CONNECT method establishes a tunnel to the server identified by the target resource.
OPTIONS. The OPTIONS method is used to describe the communication options for the target resource. OPTIONS sirve para verificar CORS!
TRACE. The TRACE method performs a message loop-back test along the path to the target resource.
PATCH. The PATCH method is used to apply partial modifications to a resource.