The HTTP Responses

Status

The HTTP response status line contains a status code. This code is used to identify wether the request went well or if an error occurred. If indeed something went wrong in processing of the request, the status code will also tell something about the type of error.

The following status codes are defined in the RE-ZIP API:

HTTP Status	Description
200 OK	Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.
201 Created	A new resource was created and a response body containing a representation of the new resource is being returned.
202 Accepted	Request was accepted but not yet processed. A Location header containing the canonical URI for the newly created resource should also be returned.
204 No Content	The server successfully processed the request, and is not returning any content.
400 Bad Request	The request could not be processed because it contains missing or invalid information (such as validation error on an input field, a missing required value, and so on).
401 Unauthorized	Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
402 Payment required	You either need to create a or upgrade your payment plan.
403 Forbidden	The server recognized your credentials, but you do not possess authorization to perform this request.
404 Not Found	The requested resource could not be found
429 Too Many 4XX Requests	The HTTP 429 Too Many 4XX Requests response status code indicates the user has sent too many requests in a given amount of time resulting in a 4XX response. A Retry-After header is included to this response indicating how long to wait before making a new request.
500 Internal Server Error	The server encountered an unexpected condition which prevented it from fulfilling the request.

Headers

Header	Description
Content-Type	The media type of the response body
Content-Length	Length (in bytes) of the response message body
Location	Canonical URI of a newly created resource - if applicable
X-Request-UUID	Optional Request UUID (v4) to identify request/response flows

Body

The response body for any non-static resource requests will contain a JSON document. The JSON-encoded data will either be a hash or a list of hashes. Here are some examples:

Response for a successful request for a single resource:

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: n

{
  "key1": "value1",
  "key2": "value2"
}

Response for a successful request for a list of resources:

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: n

[
    {
      "key1": "value1",
      "key2": "value2"
    }
]

If processing of a request fails the response may look like this:

HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=UTF-8
Content-Length: n

{
  "message": "Validation error",
  "errors": {
    "key1": ["must be at least 8 chars"]
  }
}

All error responses have message and errors keys, but errors might be NULL if fx. the error is not related to some input data.

Static resources

If the resource is a static resource the “Content-Type” header will reflect the media type in question - eg. “application/png”, “text/css” etc. The response body will contain the raw resource data or will be empty on errors.