HTTP Status Codes

Estimated Reading Time:  9 minutes

Overview

When users request data from web applications and API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. (application programming interface) services, those service's servers issue HTTP status codes in response. Creators can use these response codes to analyze if calls to web apps and APIs are successful or erroneous to adjust their requests as needed. Sometimes, end-users End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. might see these status codes when sending a request to the server. For example, an end-user might see the status code 404 in their browser if the web page they are trying to reach is unavailable.

NOTE  In Unqork, Creators can set the HTTP HTTP (Hypertext Transfer Protocol) is an application-layer protocol used to transmit hypermedia documents like HTML. response for server-side API modules.

What You'll Learn

After completing this article, you'll know the five status categories and response codes. You'll also learn how to set and test HTTP status responses for API modules.

HTTP Response Status Code Categories

HTTP response status codes break down into five category ranges:

  • 100-199: Informational Responses informing the client their request was received, and the process continues.

  • 200-299: Successful Responses informing the client their request was successfully received, understood, and accepted by the server.

  • 300-399: Redirection Responses informing the client that additional action needs to be taken to complete the client request.

  • 400-499: Client Error Responses indicating an error occurred in the client's request, or the request cannot be fulfilled.

  • 500-599: Server Error Responses indicating the server could not process a request that might be valid.

Below are the most common response codes by category.

Information Response Codes

This class of status codes indicates a provisional response provided by the server. Response codes in the 1xx range inform the client that everything is OK and the request should continue to progress.

Status Code

Name Description

100

Continue

This code indicates a client should continue the request or ignore the server response if their request has already completed.

101

Switching Protocols

This code is sent in response to an Upgrade request header from the client. It indicates the server switching protocols.

103

Early Hints

This code is used with a Link header, enabling the user to start preloading resources while the server prepares a response.

Successful Response Codes

Status codes in this range indicate a successful response. The type of success depends on the client's request.

Status Code

Name Description

200

OK

The client's HTTP request succeeded.

201

Created

Typically sent after POST requests and some PUT requests.

202

Accepted

The client request is received but the server has not acted upon it. This response is intended for batch-processing, or where another process handles the request.

203

Non-Authoritative Information

The returned metadata is not the same as what is available from the server. Typically used for mirrors or backups of other resources.

204

No Content

There is no content contained in the response, but the headers might contain useful information.

205

Reset Content

Instructs the user agent to resend the document that sent this request.

206

Partial Content

Typically used when a Range header is sent from the client for requesting only part of a resource.

Redirection Response Codes

The 3xx range of status codes indicate that a request has more than one possible response. The client might need to choose a response to continue their request.

Status Code

Name Description

300

Multiple Choice

This response is used when the client request has more than one choice.

301

Moved Permanently

The URL of the requested resource has moved permanently. The new URL is delivered in the response.

302

Found

The URI of the requested resource has changed temporarily, and further changes might happen in the future.

303

See Other

This response directs the user agent to GET the requested resource at another URI.

304

Not Modified

Used for caching purposes. Informs the client the response is not modified. The client can use the previously cached version of the response.

307

Temporary Redirect

This response is sent when the server directs the client to GET the requested resource at another URI.

308

Permanent Redirect

The resource has permanently relocated to another URI specified by the Location response header. This is similar to the "301 - Moved Permanently" response, but it instructs the user not to change the HTTP method if a POST is used in the first request.

Client Error Response Codes

Status codes in the 4xx range indicate an error in the client's request. User agents should display these codes to the end-user when they occur.

Status Code Name Description

400

Bad Request

This response occurs when the server cannot or will not process the request due to user error.

401

Unauthorized

The user is unauthenticated and must authenticate to get the requested response.

403

Forbidden

The requester does not have access to the content. The server refuses to deliver the requested resource.

404

Not Found

The server cannot find the requested resource.

  • In a browser: The URL is not recognized.

  • In an API: The endpoint might be valid, but the requested resource does not exist.

405

Method Not Allowed

The target resource does not support the request method.

406

Not Acceptable

This response occurs after server-driven content negotiation fails to find content that conforms to the request issued by the user.

407

Proxy Authentication Required

Authentication needs to be completed by a proxy.

408

Request Timeout

Servers send this response to close out idle or unused connections.

409

Conflict

There is a request conflict with the current state of the target resource. Conflicts occur more often with PUT requests.

410

Gone

Access to the target resource is no longer available.

411

Length Required

The server rejected the client request because the Content-Length header field is not defined, and the server requires it.

412

Precondition Failed

The request has preconditions in its headers that the server does not meet.

413

Payload Too Large

The requested entity is larger than the limits defined by the server. The server might return a Retry-After header or close the connection.

414

URI Too Long

The URI request by the client is longer than the server is willing to process.

415

Unsupported Media Type

The server does not support the media format of the requested data.

416

Range Not Satisfiable

The range specified in the Range header request cannot be fulfilled.

417

Expectation Failed

The server cannot meet the expectation set by the Expect request header field.

426

Upgrade Required

The server refuses the request using the current protocol, but might accept it after the client upgrades to a different protocol.

428

Precondition Required

The server of origin requires the request to be conditional. This is intended to prevent lost updates.

429

Too Many Requests

The user has sent too many requests in a given period of time.

431

Request Header Fields Too Large

The server refused the request because its header fields were too large.

451

Unavailable For Legal Reasons

The request cannot be legally provided. This error might occur when a government censors a web page.

Server Error Responses

Status codes in the 5xx range indicate cases where the server is aware that it has erred, or is unable to perform the request. User agents should display these codes to the end-user when they occur.

Status Code

Name Description

500

Internal Service Error

This server has encountered an issue it is unable to handle.

501

Not Implemented

The server does not support the client request method. The only required methods that servers support are GET and HEAD.

502

Bad Gateway

While working as a gateway, the server receives an invalid response.

503

Service Unavailable

The server is not prepared to handle the request. This might occur if the server is down for repairs or overloaded.

504

Gateway Timeout

While working as a gateway, the server cannot get a response in time.

505

HTTP Version Not Supported

The Server does not support the HTTP version used in the request.

506

Variant Also Negotiates

The server has an internal configuration error: the chosen variant resource has been configured to engage in transparent negotiation itself instead of an end point.

510

Not Extended

Further extensions to the request are required for the server to fulfill it.

511

Network Authentication Required

The client needs to authenticate to gain network access.

Setting HTTP Output Response Codes For API Modules

For improved error handling, HTTP output codes can manually be set for server-side API calls in Unqork. This lets you specify what response codes can be produced by the API call.

The supported status code categories for server-side API calls in Unqork are:

  • 200-299: Successful Response Codes

  • 400-499: Client Error Response Codes

  • 500-599: Server Error Response Codes

NOTE  The API module must be set to server-side execution to enable the HTTP Output function. To learn more about module settings, view our Module Settings article.

TIP  To learn how to build an API module with the API Specification snippet, visit our API Specification snippet article.

What You Need

To add HTTP output to an existing API module, you need:

Configuration

Configure the Initializer Component

In the snippet, configure the Initializer component to trigger the Decisions component that manages HTTP responses.

1. Open the API module containing the API Specification snippet.
2. In the panelConfig Panel Component Icon Panel component, hover over the Initalizer Component Icon Initializer component.

A 5-button toolbar displays above the component on hover-over.

3. Using the toolbar, click the (Settings) button.
4. In the Outputs table, enter the following:
  Property ID Type Value

1

ruleHTTPresponses

trigger

GO

5. Click Save & Close.

Configure the Decisions Component

This component is where you'll set the rules to produce HTTP response codes for your API.

1. In the panelConfig Panel Component Icon Panel component, hover over the ruleHTTPresponses Decisions Component Icon Decisions component.

A 5-button toolbar displays above the component on hover-over.

2. In the Inputs table, enter or verify it contains the following:
  Property ID Type

1

requestParameter

exact

3. In the Outputs table, enter or verify it contains the following:
  Property ID Type

1

sse.httpResponseCode

value

NOTE  The sse.httpResponseCode Property ID changes to sse['httpResponseCode'] after saving. The functionality of the HTTP output response is not affected by this.

4. In the Micro Decisions table, enter the following:
Input Values Output Values
requestParameter sse['httpResponseCode']_value

valid

200

invalid

400

error

500

A static image displaying the "ruleHTTPresponses" decisions component. The Inputs, Outputs, and MicroDecisions tables are filled out.

5. Click Save & Close.

Your API module is now configured to produce HTTP response codes defined in the Decisions component.

Testing HTTP Response Codes with the Server Side Execution Testing Page

Test the API module's HTTP response code output using the Server Side Execution Testing page. The server side execution test page verifies the request parameters and outputs the status code associated with each parameter.

TIP  To learn more about the Server Side Execution Testing tool, visit our How to: Use the Server Side Execution Testing Page article.

To test the HTTP response codes:

1. At the top right of the Module Builder page, click the Server Side Execution button.
2. In the Data Key field, enter requestParameter.
3. In the Data Value field, enter invalid.

A static image displaying the Server Side Execution Testing page. The Data Key is set to "requestParameter" and the Data Value is set to "invalid".

4. Click the Execute button.

Because the requestParameter key is set to invalid, the response debugger displays the Response Status as an HTTP status code of 400, indicating a successful invalid response.

A static image displaying the response status "400"  when the Data Value is set to "Invalid".

5. Repeat the process for each request parameter set in the Decisions component to verify the Response Status changes in value.

Resources