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

200OKSuccessfully executed. should be used to indicate nonspecific success
201CREATEDSuccessfully 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
202ACCEPTEDThe 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)
204NO_CONTENTThe 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
301MOVED_PERMANENTLYThe new location should be returned in the response ( should be used to relocate resources)
302REDIRECTThe HTTP response status code 302 Found is a common way of performing URL redirection.
400BAD_REQUESTMalformed or invalid request
401UNAUTHORIZEDInvalid authorization credentials. (no autenticado, o autenticado incorrectamente)
403FORBIDDENDisallowed request. Security error. (no autorizado para ver pagina/recurso)
404NOT_FOUNDResource not found.
Ejemplo: Si se busca un cliente por rut y éste no existe, el estado es 404
405METHOD_NOT_ALLOWEDMethod (verb) not allowed for requested resource. Response will provide an “Allow” header to indicate what is allowed
412PRECONDITION_FAILEDOne or more conditions given in the request header fields evaluated to false when tested on the server.
415UNSUPPORTED_MEDIA_TYPEClient submitted a media type that is incompatible for the specified resource.
422UNPROCESSABLE_ENTITYSe 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.
418I'm a teapotLudic HTTP
500INTERNAL_SERVER_ERRORCatchall for server processing problem
503SERVICE_UNAVAILABLEResponse in the face of too many request
504GATEWAY_TIMEOUTserver 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:
 

  1. GET. The GET method requests a representation of the specified resource. Requests using GET should only retrieve data. (idempotent)
  2. 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)
  3. HEAD. The HEAD method asks for a response identical to that of a GET request, but without the response body.
  4. PUT. The PUT method replaces all current representations of the target resource with the request payload.
  5. DELETE. The DELETE method deletes the specified resource.
  6. CONNECT. The CONNECT method establishes a tunnel to the server identified by the target resource.
  7. OPTIONS. The OPTIONS method is used to describe the communication options for the target resource.  OPTIONS sirve para verificar CORS!
  8. TRACE. The TRACE method performs a message loop-back test along the path to the target resource.
  9. PATCH. The PATCH method is used to apply partial modifications to a resource.


more details:

  • HEAD - No defined body semantics.
  • GET - No defined body semantics.
  • DELETE - No defined body semantics.
  • CONNECT - No defined body semantics
  • PUT - Body supported.
  • POST - Body supported.
  • TRACE - Body not supported.
  • OPTIONS - Body supported but no semantics on usage (maybe in the future).


Mayor información

Blog Archive

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.