HTTP Status Codes
HTTP status codes break down into the following categories:
- 100-199: Informational messages
- 200-200: The message was successful
- 300-399: Redirection
- 400-415: Error on the client side
- 500-599: Error on the server side
Recognizing the general numeric category could be helpful in tracking down the source of an error.
The table below provides information on some of the more common HTTP error codes you might encounter when working with the Akana API Platform API. For a full list of HTTP error code numbers and meanings, refer to the HTTP spec.
HTTP Code | Body | Cause/explanation/examples |
---|---|---|
Success codes: | ||
200 | OK | The request completed successfully. |
201 | Created | Successful create (add) request. |
204 | No Content | The server successfully processed the request, but is not returning any content. |
Redirect codes: | ||
302 | Redirect | Redirect found. The client should use the URL given in the Location header. |
Client error codes: | ||
400 | Bad Request | Returned if the client sends invalid parameters or body content. For example, you might get this response if there is a typo in the request URL, or if you send malformed XML in your request (if applicable). |
401 | Unauthorized |
Authentication (login) is required for this operation. For example, perhaps a required cookie was not included. You would get this response if you didn't include the custom X-Csrf-Token_{fedmemberID} header in the request, or if it was invalid or expired. |
403 | Forbidden | Authentication is required. |
404 | Resource not found | The information in the path, parameters, or message header/body didn't match up to any available resource at the specified URL. For example, the message has the wrong content-type, a typo in a parameter, or a wrong accept-header; or you might get this error if a specified resource, such as an app, API, or rating, does not exist. You would also get this if you were using the wrong HTTP verb. |
405 | Method Not Allowed |
The request is using an HTTP verb not supported for the resource (at that endpoint/URL). If the operation doesn't support the HTTP verb—for example, if POST is used but only GET is supported—the response includes an Allow header with a list of the HTTP methods (HTTP verbs) that are valid for the resource. For example, the following Allow header was returned for a POST operation that was attempted with a GET HTTP verb: allow POST |
406 | Unacceptable/Not Acceptable |
Returned if the response format, as specified in the Accept header, does not match the content type specified in the request. For example, you might get this response if you set the Accept header to text/xml for an operation that only returns an application/json response, such as GET /api/apis/{APIID}/followers. It indicates that there is no format that the operation can return, that matches the format or formats specified in the Accept header. Therefore any possible response is "not acceptable" per the specification in the Accept header. |
409 | Invalid action for current resource state | The action attempted was not valid for the current state. For example, the message is attempting to cancel an API contract that doesn't currently have a status of Approved. |
415 | Unsupported Media Type | Returned if the request is using a media type not supported by the method. |
Server error codes: | ||
500 | Internal Server Error | An error occurred while processing the call. This error is generally returned for any business logic failure that doesn't fit into any of the defined categories above. |