Body editor
This page describes how the body editor works in Advanced REST Client.
Last updated
This page describes how the body editor works in Advanced REST Client.
Last updated
This documentation is for ARC version 16 and up.
Body editor allows you to define the message body to be sent to the API. You can see the body editor for all operations but GET and HEAD. While the HEAD operation has no message body per the HTTP specification, the GET operation is not supported in ARC because all web clients don't support it. The GET operation should not carry the body.
The row body input allows you to define any text message to be sent with the HTTP request. On the right-hand side of the editor, you can choose one of the popular mime types for the request. This will enable syntax highlighting and syntax validation.
By default, the syntax depends on the current Content-Type header in the headers editor. When you switch the value in the mime type selector, then the header value is updated. This also works the other way around. When the Content-Type header value changes in the editor the body editor will start using it for syntax highlighting.
When the endpoint accepts the www-url-form-encoded values, you can use the URL from-enoded editor to build the message. It renders a form of parameters and takes care of the final formatting of the message.
The final message would be something like the following:
Sometimes the name or the value field is highlighted with the error color. This means the entered value is not properly encoded.
In this situation simply press the Encode Values button to fix this problem. The form names and values are then encoded according to the URI specification.
Another time you may see the message: "The content-type header has a different value than www-url-form-encoded."
This warning message is to inform you that you have selected the www-url-form-encoded editor but the current value of the Content-Type header in the headers editor is different. If you won't fix the problem the server will probably read the message incorrectly or at all. Use the Fix button to replace the header value in the headers editor.
Advanced REST Client has a dedicated multipart form data editor. The multipart body allows you to define a message that is composed of multiple separated parts. Each part has its own message body, encoding, and even file name. When you are testing an API endpoint that accepts the multipart form data message then use this editor to construct your message using the form-based interface.
Current only the multipart/form-data is supported. Other multipart/* parts are not supported.
You can define 3 types of form parts. The file part allows you to select a file from your local drive and to specify the field name. The application takes care of the formatting of the message. The text part allows you to define a plain-text part of the message. In this part editor, when you specify the mime value, it will become the formatted text part. The value of this part is sent with the specified mime.
You don't need to specify the "boundary" of the content-type header. The application will generate one for you when the final message is generated. The final content header can be something similar to the following:
The file editor allows you to select any file from your local drive and send it with the HTTP message. The file can be any file. You can even send a JSON file like this and the sent message will have the JSON content as it would be read from the "raw" editor.
When a request is sent a proper Content-Type header is inserted according to the file mime type.
Each editor saves its own state. This means that when you switch from one editor to another the previously set value is restored and the HTTP body value is the one restored from the editor's state. This is a different behavior compared to previous versions of ARC where different editors were trying to use the same values. This was potentially leading to a data loss. Because of that, the behavior changed.
