Sending requests
This guide describes how to make an HTTP request to the API endpoint
Last updated
This guide describes how to make an HTTP request to the API endpoint
Last updated
This documentation is for ARC version 16 and up.
The requests workspace is the main part of the application. It allows you to open multiple requests in a single view. The workspace hosts tabs for the HTTP or web socket editors. To choose between them long-press the add button in the tabs line.
In the request editor, you build the HTTP request to make an API call. You have to provide at least the operation (HTTP method) and the URL of the API resource. The editor also allows you to define HTTP headers and the message body (when applicable to the selected operation). Here you can also define authorization strategy by configuring one of the supported authorization schemes, request actions, and request execution configuration. Finally, you can also generate code snippets for the current request.
The HTTP request URL is an API endpoint URL you want to perform an operation on. The input field allows you to provide any valid URL data, like, https://api.domain.com/endpoint?param=value
The URL is passed to the HTTP client unprocessed to give you more control over request parameters. This means that special characters must be encoded before sending the request.
You can edit query parameters directly in the URL field, but the URL editor has a convenient parameters editor to provide the values and to encode or decode the URL.
You can disable query parameters. They won't be included in the request, but they can be enabled later when needed.
When you see an error indicator in the query parameter this means that the value is invalid per URI scheme specification. Use the Encode URL button to fix the problem.
Once encoded value will be encoded again producing an invalid entry. When you want to encode values again, decode the values first and then encode them.
Typical REST operations are:
POST - create a resource
GET - read a resource or a collection of resources
PUT - update a resource by providing a new value to replace the old one
PATH - update a resource with only a part of the resource
DELETE - deletes a resource
There are less commonly used methods and Advanced REST Client supports them all but for the purpose of this tutorial we ignore them as probably, you won't use them.
The headers are additional meta-information sent to the server to inform it how to process the message. There are well-defined request and response headers like content-type or accept. Your API, however, may require custom headers. The headers editor allows you to define these headers.
ARC does not generate any request headers with exception of theHost header which is required to make a request. Unlike other HTTP clients, only headers that are defined in the editor are sent to the server. This behavior can be configured in the settings.
By default, you see the headers form. Add a header by clicking on the Add button. Start typing a header name. The editor renders suggestions if the header name is one of the defined in the specification headers.
Similar to query parameters, headers can be temporarily disabled to test various options. When the toggle button is unselected then the header value is kept in the editor but it is excluded from the request.
You can switch to the text editor to enter the values manually.
The body is the message you want to send to the server. In RESTful APIs, this is the resource you create or update.
GET and HEAD methods cannot define a body on a request. Even though it is technically possible, clients probably won't work with such a request.
You don't need to set the Content-Length header. It is added automatically when preparing the message. When this header is defined in the headers list it will be used instead. This way you can test your server for invalid input.
The body editor supports syntax highlighting for several content types like JSON and XML. You can switch between different types of body editors. See a related article about editing the body.
The authorization editor supports several authorization strategies like basic scheme, OAuth 2, client certificates, and so forth. The authorization configuration is described in the related document. You can use more than a single authorization strategy at the same time.
When selecting a strategy don't forget to enable it in the selector or otherwise it won't be used with the request.
Request actions are the ARC's way to perform some tasks when the request is executed. Actions are executed before and after the request updating your environment. Actions can be conditionally executed, meaning the action runs when a specified condition on the HTTP request data is met. For example, you can check whether a response has the desired status and set a variable from the response body. You can learn more about request actions in the dedicated section.
In the request editor, you can set per request configuration options that override the global settings for the HTTP request processing.
