Remixing APIs Using Mock APIs In Postman Collections
I had found the NAICS API the other day, but after I got using it I realized that there had been a newer release of the NAICS standard in 2017, which had occurred since the API was published. I also didn’t much care for the schema of the responses for the NAICS API—while it was complete, it wasn’t very applicable to what I was publishing. To simplify things, I took a stab redesigning the JSON response, taking what I feel is better advantage of the NAICS structure and layering the JSON along with the NAICS schema. This 2017 collection doesn’t completely replace the 2012 version, as the older version still has its place, but it does provide a more up to date look at the current business sector landscape. I took the resulting JSON and I crafted and published to Github as a Gist, but then I also got to work publishing it as a Postman API collection that could be easily mocked and made available for applications, visualizations, and even the delivery of a new API.
As I was reworking the JSON structure for NAICS I was thinking more deeply how it could best be used as an API, I realized I could use Postman collections as a way to remix the NAICS API and suggest the potential next version of the API specification. Now, maybe others will not like my structure in the same way I found the 2012 edition difficult to work with, but maybe they also find it more usable in their own work. Either way I think it is an interesting way to remix, then share the results of the remixed API with other stakeholders and the community to gather feedback on the approach. With the request and mock structure of Postman collections it lends itself to many different ways to collaborate around the design of an API, with multiple channels which you can leverage to gather feedback—making it a pretty versatile API development environment (ADE).
I really like this approach for managing simple data sets, and APIs. It allows you to take existing schemas from XLS, XLSX, CSV, and JSON files and quickly turn them into mocked APIs that exist as a portable unit you can share via link, workspace, or via published API documentation from your collection. My NAICS collection (2017) doesn’t have all the functionality of the NAICS API collection (2012), but it does have all the same data available as a single JSON file. I could easily go further and break down the requests and examples into different requests, with the relevant subset of the data available, but I think this is a good first start for not just delivering a remixed API, but an updated 2017 edition of NAICS, complete with a Postman collection and documentation for easy use—allowing anyone to import the collection into their own workspace, mock the API, and be up and running within their application within minutes.
At some point I will publish my NAICS mock API as a real API—maybe. I might just leave as a JSON file and use it wherever it is needed. Right now it is just driving my search vocabulary, so I’m not sure it will be needed as an API. When I need it again I may just use the mock server to load the data, do some manipulations and publish whatever the desired result our output is. If I started using it a lot, I’ll consider publishing an actual API for use in my applications, but until my mock traffic goes up I’m not going to invest more time into this API—using my Postman mock API traffic as a sort of measurement for when one of my simple data APIs should become real APIs. For many of my datasets, which I may only use once or twice a year so it might be adequate for them to just live as static collections in a variety of my API workspaces, saving me the overhead of actually operating as APIs.