Restlet Blog

You’ve certainly heard about DHC (aka Dev HTTP Client) joining the Restlet family a few months ago. DHC 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 DHC in your Chrome browser.

Installing the tool

The tool for API testing can be used as an online service from https://dhc.restlet.com/ or installed within Chrome from the Chrome Web Store.

dhc-image08

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

Executing a request

The main feature of DHC 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

DHC 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.

dhc-image10

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.

DHC 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.

dhc-image19

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. DHC provides a set of types right below the text area to directly set the corresponding content type value.

dhc-image22

  • Content from file (file value). In this case, DHC 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.

dhc-image14

  • Forms (form value). DHC 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.

dhc-image02

dhc-image27

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.

dhc-image24

What is really nice with DHC 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

DHC 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.

dhc-image06

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.

DHC 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.

dhc-image07

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

dhc-image17

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.

dhc-image26

dhc-image28

dhc-image23

DHC 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.

dhc-image18

DHC 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.

dhc-image05

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.

dhc-image25

Export request as…

DHC 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.

dhc-image12

Organizing requests

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

Leveraging projects and services

Once a request is created and named, DHC 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. DHC gives you the ability to create your own projects and services if none match.

dhc-image09

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.

dhc-image21

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

dhc-image11

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.

DHC 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.

dhc-image03

dhc-image01

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

dhc-image15

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

dhc-image04

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.

dhc-image20

Importing and exporting requests

The import / export feature of DHC 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:

dhc-image16

Importing

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

dhc-image13

Exporting

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

dhc-image00

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

CTA_free trial_3

7 Comments

  1. Pingback: This week in API land #26 | Restlet - We Know About APIs

  2. 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?

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

  4. Pingback: Import CSV files in your API’s data store | Restlet - We Know About APIs

  5. 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.

  6. Pingback: Testing RESTful services with DHC by Restlet | Restlet - We Know About APIs

  7. 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.

    Thanks.

  8. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *