The popular Postman application programming interfaces development platform has gone back to its web-based roots and introduced Postman for the web, a breakthrough browser interface to make creating, using, and testing APIs easier. If you are writing code today, you are probably architecting it for high levels of reuse. Gone are the days — well, hopefully — where you have multiple developers writing the same code for the same purpose. Instead, developers are thinking in terms of a service-oriented architecture. This type of architecture starts with writing the business logic once and then reusing it wherever it is needed. For example, let’s say you have an app that enables a customer to sign up for your website. That signup form might look one way on a browser and completely different on a mobile device, but it is the same exact code that processes the request and writes it to the database. If there is an error in the signup process, that code always returns the same error message or warning, and any version of the app can display the same information.
Write once, use everywhere
If you follow my writings on this topic, APIs continue to grow in popularity as software developers write their code to be shared with others, be it for internal use, free, or as a paid service. Developers want other developers to use their code and not have to understand the underlying functionality. Going back to that example where you write an API to create a customer, that code might check for a valid email address, ensure there are no duplicates in the database, create a new record in that database, and send user-friendly messages back to the calling code. To the person writing the app, they are using whatever language they are comfortable using and calling a “CreateCustomer” API that exists in your corporate network or the cloud.
Write once, make money from everyone
For developers, using APIs is very powerful and dramatically reduces the risk of writing buggy code, and it is a boon to organizations offering their APIs to sell their services. Even though Microsoft Azure and Amazon AWS have a pretty frontend, they are just a set of exposed APIs. For example, if I had a project that required I spin up twenty new virtual machines, I could go to the Azure website and manually add one, answering all the questions and going through all the wizards, then another following the same steps, and then finally two hours later, I am done. However, since Azure is an API, I could simply write a script that creates all twenty, and in a matter of minutes, the work is done.
The reason I use this example is there is already a massive cost saving in using cloud-based services. Still, there is another hidden productivity improvement by exposing the service as an API. Monetizing APIs is a thriving and growing exponentially. To prove my point, here is a chart from Postman, the company that makes the popular API development platform of the same name:
As you can see, in early 2015, API developers were making less than half a million API calls. Now, in late 2020, the product reports just over a billion API calls.
The business of writing APIs
As APIs become more popular, there is an increasing amount of pressure to create them right the first time. Using my little example of an API that creates a new customer, your API should probably ask for the bare minimum to do so. Even though your database may have fields for the customer’s first name, last name, physical address, credit card number, email address, and other information, the API should only require fields that are necessary at that time. I, for one, would never go filling out all those fields on an app just because I want to try it out. Developers know I might delete the app before even starting, so they create a “CreateCustomer” API, then another “UpdateCustomer” API. The “CreateCustomer” API might just ask for an email address and password. The “UpdateCustomer” API, on the other hand, will ask the user for the information when it is needed. For example, the app will call “UpdateCustomer” only when it is time to ship me goods and needs my billing and shipping information.”
Writing APIs does not just mean collecting and sending data. You need to think about the API holistically, considering not only about how the developer will use, but how a designer or front-end developer will incorporate the data into a user interface. Further, the API needs to be scalable, so code is not sitting around waiting for a response over long periods. They need to be optimized for use. Sharing how to use your API correctly is essential, so smart developers package up their APIs and documentation, so it is easy for other developers to get up and running. As you can see in the following image, Postman has a feature called Collections to facilitate that easy exchange of API documentation.
As you can see, there are nearly 50 million collections in Postman today, many of which are distributed by companies like Cisco and others, hoping you will use their APIs.
Introducing Postman for the web
If a developer is going to create, use, or test APIs, it needs to be easy. Believe me, if a developer does not find something easy, they will move on and find something else, and with the market growing exponentially, there are always more options. With that competitive landscape and with the pressure to build more — and more robust — APIs, development must be easy and accessible for the developer.
As with any software code, creating and using APIs have their challenges. Postman, a company whose namesake product is popular among developers but requires a stand-alone product install. The requirement to install an app on your local computer can hinder collaboration and adds another level of complexity when trying to get up and running with the product. Postman for the web is aimed at addressing that hurdle. As you can see from the chart below, developers will see dramatic improvements in time savings as they develop and test their APIs using the new web-based version.
Hey, hand me that CORS
Before Postman, the desktop app, it started as a little app on the Chrome web store. However, creating a full-scale app that could handle API calls from any web URL is no easy task, most of which comes from the CORS problem.
CORS, or cross-origin resource sharing, is a security measure browsers have in place that helps to prevent a secure website from accessing information from an [potentially] insecure location. This built-in security is critical to how we protect the web, but developers have a lot of hoops to jump through when trying to create and use APIs. This Wikipedia link is an easy read to understand how CORS works and the challenges it brings to browser-first web development.
Since Postman for the web is based on standard browser technology, calling any API from any source is a serious challenge with CORS, so Postman created a method to make it easy for any developer to access their APIs. Per Postman, they created a “proxy micro-application to facilitate API request-sending at scale, the agent conquers this browser challenge in a way that’s never been done before.”.
Postman for the web: New product, familiar UI
When Postman informed me they created a new web-based version of their product, my first question was, “How similar is it to the desktop version?” After a few discussions, I received an early preview of the product, which officially releases today. If you are familiar with the Postman user interface, you can see that Postman for the web draws heavily from the desktop interface, which should make for a welcome transition.
If you want to try Postman for the web, check it out here.
Featured image: Shutterstock