API Building and Testing Made Easier with Postman

Postman logo

An API (application programming interface) is a medium of interaction between applications. APIs that use HTTP or HTTPS are called Web APIs.

If you look around on the Internet, a large number of services use APIs. Anything with a social login uses an API; the mobile application of an ecommerce site uses an API; even the ads that you see on the Internet use APIs!

By creating an API for your service, you enable third-party developers to create applications based on your service. For instance, the social newspaper Frrole uses the Twitter API to generate contextual insights by analyzing a large volume of tweets.

Assuming you have assessed the pros and cons of creating an API, let’s talk briefly about the process of creating and testing APIs.

Creating APIs

Although there are many ways of creating an API, a Web API is created using the REST (Representational State Transfer) framework. The REST framework states a set of guidelines that one must follow while creating an API. With the large number of APIs being created daily, it serves as a standard for Web-based APIs.

The four most common actions performed through APIs are view, create, edit and delete objects. The REST framework maps four HTTP verbs to these actions: GET, POST, PUT and DELETE. There are many verbs that have been added to this list like PURGE and PATCH, but in this article, we’ll talk about only the four basic ones. This article on the best practices for a pragmatic RESTful API, by Vinay Sahni, founder at Enchant.com, may be useful for a first-time developer.

Nowadays, there are many frameworks that provide wrappers over the basic HTTP layers, thus making your life as a developer easier. All you need to do is invoke the required commands or functions and focus on the functionality. Popular examples include Slim and Toro, two PHP-based micro frameworks that help you create REST APIs quickly.

Testing APIs through the CLI

The prime motive of creating an API is to enable other applications (which may be yours or developed by third parties) to use the services. Therefore, at every stage of the API development process, a critical part is testing the API for functionality, exception handling and security.

Using an API involves a request to the required resource (usually a URL) using one of the verbs (or methods). You may have to add headers depending on the requirements of the API you’re using. One way to request such a resource is through the command line.

In this post, we’ll concentrate on four parts of an API call – the URL, the HTTP verb, the headers and parameters. We’ll use the cURL library to send requests to the API resources through the CLI. cURL is a command line tool that helps in transferring data with URL syntax – supporting FTP, FTPS, HTTP, HTTPS.

Let’s look at the following command:

curl -i -X POST -H "Content-Type:application/json" http://www.my-api-example.com:port/ -d '{"Name":"Something"}'

The -i command stands for include, which tells the command that headers are present in the request. The -X option is immediately followed by the HTTP verb or method. -H specifies custom headers that are added to the request. Finally, the -d option specifies custom form data to be passed along with the request.

The result of an API call is an HTTP response, usually encoded in the JSON format. The response is coupled with an HTTP response code, which gives information about the status of the request (like 200 for OK, 404 if the resource does not exist, 500 if there’s a server error and 403 if the resource is forbidden). For instance, the following response could be sent as a result of the earlier request, along with a 200 status code:

[code language=”javascript”]{“message”:”success”,”id”:”4″}[/code]

Testing such responses within the command line poses a challenge too, especially if the responses have a large number of options.

A list of CLI options while testing APIs are listed in this detailed guide by Codingpedia.

Continue reading %API Building and Testing Made Easier with Postman%

Source: Sitepoint