- October 19, 2015

You’ve certainly heard about Restlet Client (fka DHC) joining the Restlet family a few months ago. Client is an awesome API testing tool to interact with REST services. You’re probably wondering what’s so different about this tool? In fact, it’s a lot of small things that make your user experience better, save you precious time when debugging REST calls and even sharing your requests with other people.

Throughout this article I’ll show the capabilities of the tool and convenient tricks pretty much everywhere. Let’s start by installing Client in your Chrome browser.

Installing the tool

The tool for API testing can be used as an online service from or installed within Chrome from the Chrome Web Store.


The tool is then available in your Chrome applications through chrome://apps.

Executing a request

The main feature of Client is dedicated to API testing, and to go deeper it helps every REST client to provide a way to build a request and display the response.

Making the request

Restlet Client provides a dedicated area to configure the request. This area maps the different request elements. The latter is summarized in the following figure as a reminder.


Here are some details about these elements:

  • The protocol to use to interact with a server.
  • Host and port identify the target to contact to send the request. Once connected to the server, the path is used to select the resource to handle the request.
  • The method corresponds to the HTTP verb used. It identifies the action to execute on the resource.
  • Query parameters are used to build the query string of the request. They contain data that doesn’t fit conveniently into a hierarchical path structure.
  • HTTP Headers define the operating parameters of an HTTP transaction. They correspond to a list of key-value pairs.
  • Request payload corresponds to the data sent when supported. This applies to methods POST, PUT and PATCH.

Client defines four distinct sub areas: the request URL and method, the query parameters, the headers and the request payload. The following screenshot describes the case of a GET method where no payload is used. By default, the query parameter area is hidden and can be displayed by clicking the “?” character right after the address field. You can either directly leverage the URL to add them or use the form. The main difference is, when using the form, parameter values are automatically URL encoded.


A POST method follows the same approach but in addition a request payload can be added. Several modes are supported for payload content. The switch is done using the combobox on the top right hand corner of the body area.

  • Text content (text value) for formats like raw text, JSON, XML or YAML, with nice syntax highlighting. In this case a text area can be used. Client provides a set of types right below the text area to directly set the corresponding content type value.


  • Content from file (file value). In this case, Client provides an area to drag’n drop the file or select it explicitly. The tool automatically gets the associated mime type. When clicking on it, the Content-Type header is automatically created.


  • Forms (form value). Client supports both simple forms and multipart ones. With the first kind, only text form elements can be defined and the content type is set to application/x-www-form-urlencoded. With the second one, you can mix file elements with text ones. In this case, the content type is multipart/form-data.



Another thing is the ability to disable some elements in lists (query parameters and headers) without having to remove them. This is particularly useful when building your request to tweak it and reach the expected behavior.


What is really nice with Client is the ability to switch mode to edit and display things. For example, you have access to the raw content or manage it using a form view.

Displaying the response

Client provides a dedicated area to display the response. This area maps the different response elements. The latter is summarized in the following figure as a reminder.


Here are some details about these elements:

  • The status code and message correspond to the status of the response. The status code is a normalized number. HTTP defines different families at this level: 2xx for success, 3xx for redirection, 4xx for client errors and 5xx for server errors.
  • HTTP Headers define the operating parameters of an HTTP transaction. They correspond to a list of key-value pairs.
  • Response payload corresponds to the data received when supported. This applies to all methods except HEAD, DELETE and OPTIONS.

Client defines three distinct sub areas: the response status, the headers, and the response payload. The following screenshot describes the case where some payload is received in the response. In the case of structured text payload, the formatted mode is selected by default to display data using a tree. Raw mode is also available to content as text.


If no payload is received in the response, the body area remains empty.


In the case of binary content, several modes are available to preview the content (for examples, see images below) and display it as hexadecimal or raw.




Client provides support of hypermedia links within response contents by making them clickable. This way you can follow links to execute other requests very simply. When clicking on a link, a new request is automatically created.


Client provides a very helpful toolbar at the response level. This allows you to leverage the response content for different use cases: re-use the response content within a new request (button “2Request”), copy or download the response content.


Raw-level exchanges

The HTTP tab at the bottom of the page displays what is actually exchanged with the server in a synthetic way. At a glance, you can see the different elements.


Export request as…

Client provides the ability to export the request as code. At the moment only curl is supported but this small feature is very convenient for developers who love command-line approach. You don’t need to build it with different options. Working command is directly provided.

You just need to click on the button “2 Code” right around the request name to get the corresponding curl code.


Organizing requests

It’s a real pity to only define one-shot requests. An interesting approach consists of reusing and even sharing them. Client offers an interesting feature for this.

Leveraging projects and services

Once a request is created and named, Client lets you save it. The API testing tool provides the following structure to organize your requests: the first level consists of projects which provide a high-level container. They can contain a set of services that in turn contain requests.

Such elements are created when you import requests or when you save requests. Client gives you the ability to create your own projects and services if none match.


Documenting projects, services and requests

At each level (project and service), you can add documentation. When clicking on the overview element in the left menu, related hints are displayed in the right panel. Navigation is supported at this level making it possible to walk through the project.


For request, there is no field description but the name should be self descriptive in order to tell what the request actually does.


Leveraging context attributes

If you use a REST client in the context of application development, you probably have different environments like development, staging, and production. The need to rewrite requests according to these environments can be very time consuming.

Client provides an interesting and powerful feature to use variables in requests. This corresponds to context attributes. In the left panel, you can use the contexts tab to define context and the attributes they contain. Attributes correspond to a list of key / value elements.



A toolbar is available in the bottom to manage the contexts:


Context attributes can be then used at any place in the request like address, headers, query parameters and text / form payloads.


The set of attributes used is from the selected context. You can then see in the history tab that the context attribute is taken into account when executing the request.


Importing and exporting requests

The import / export feature of Client can be accessed via repository tab. There is a check icon that is displayed when the mouse is over the “My Drive” entry, as described below:



When importing a file in Client, you can select which parts (projects and services) will be taken into account. This allows you to import only a subset of data.



The same approach is possible when exporting a set of requests, as described below:


I hope you enjoyed discovering Client with me, and stay tuned for more articles on the cool features of Restlet Client, the most powerful API testing tool!


  • Pingback: This week in API land #26 | Restlet - We Know About APIs()

  • adam

    I really like the dynamic variables. I cannot work out how to use them in a context.
    For example I have a header “ticket” which is {“Ticket”.response.body.serviceTicket}
    I can provide this in the header field and i get the dynamic request from the “Ticket” request. This works perfectly.

    However, if I want to define it as a content variable “ticket” = {“Ticket”.response.body.serviceTicket}

    and then reference {ticket} as a header, the string does not resolve to the ticket, but just a text string.

    I am sure i am missing something basic?

  • This is very cool. Thanks for packaging it as a Chrome extension!

  • Pingback: Import CSV files in your API’s data store | Restlet - We Know About APIs()

  • David Hoots

    I love this extension, but I sure do wish I could delete stuff that I don’t need anymore. That seems like a pretty basic need.

    • Hi David,

      Sorry for the late answer.

      You can delete requests, projects,… using the drop-down menu present for each item displayed in the “Repository” panel (cf screenshot).

  • Pingback: Testing RESTful services with DHC by Restlet | Restlet - We Know About APIs()

  • Chris Hayes

    I’m performing a GET which returns several pages of returned but I only seem to get access to the first 100 elements. Is there a way to access elements beyond the first page? I’ve scoured the DHC interface and looked around on the net and I can’t find any controls for traversing the returned element list. Any advice would be welcome.


    • Hi Chris,

      Most of times you can specify the page, number of elements in page you want to get based on specific headers or query parameters. But it’s specific to each RESTful services (for example with Github see this link: It’s up to you to specify these hints in DHC…

      Hope it helps you,

  • krish

    i’m performing post request is there any way that i can call the data from the response of a previous request as a parameter to the new request . if possible i’ll be in a position to run all my requests in a scenario at one go .
    please let me know if there is a way to it.

  • Retro

    Is there any way to upload more than one file using Rest-Client?