I was demonstrating to to someone how you can document the Food and Drug Administration (FDA) National Drug Code (NDC) API using Postman and I found a way to enrich real world APIs by publishing mocked data APIs alongside the primary APIs within the same Postman Collection. The URL structure of the FDA DNC API (acronym congestion) is pretty simple https://api.fda.gov/drug/ndc.json?search=brand_name:"xanax"&limit=100, and it is an open API so you can jus take that URL and see a response without putting in an API keys or tokens. The API provides a suite of keywords you can query as part of the search parameter, with the only two I’m focused on being “brand_name” and “active_ingredients”, providing fairly straightforward querying capabilities, but there are some gaps in their documentation approach. They provide a wealth of ways (PDF, Excel, YAML) to get what fields you can filter by, but not any more information on useful and accepted values for those parameters.
For what I was working on, I needed two lists of values: 1) brands, and 2) active pharmaceutical ingredients. Without them you have to kind of just bumble around until you find the right values, and slowly reverse engineer what the possibilities are. These types of gaps are common with API providers, and maybe the FDA has the values somewhere else on their website, but I can’t seem to find them. I looked for a while and then began widening my scope beyond what the FDA provides, finding brands on Wikipedia, and active pharmaceutical ingredients on another 3rd party site. These tables can quickly be converted into CSV and then JSON files, which I can then turn into mock APIs using Postman collections. All I do is create new requests for my mock endpoints, add the resulting JSON as an example, and then publish my collection as a new mock server. I can tweak my variable urls for the live and mock versions to accommodate localized versions living side by side with the live FDA drug database.
Now I have a collection for directly querying the FDA National Drug Code API directly, as well as two separate enablement APIs for branding and active pharmaceutical ingredients (which is an API API) that are just mocked postman requests with examples for each of the responses. Allowing me to quickly get at brands and active pharmaceutical ingredients to make queries against the FDA National Drug Code API. Continuing to push forward how I use Postman collections. Helping me smooth out the friction with APIs introduced through inadequate API design or documentation, and provide a localized and executable collections that anyone can import and use in their own Postman API development environment. Helping make APIs easier to use by developers from the outside, augmenting what is already in place with more information, so that developer are more successful when putting an API to work.
Now that I have this design pattern in my toolbox I will keep refining upon and use it to help me create other relevant collections. I’m enjoying pushing the boundaries of what I knew could be done with Postman Collections. It has shifted by perspective of not just Postman, but of the API lifecycle and how the API provider and consumer can interact. Breaking the normal cycles of behavior we see around APIs, and empowering the community to help improve upon APIs that already exist and just haven’t receive the amount investment and energy to make them usable. Not everyone understands the potential of Postman collections and how they can be used, so I want to keep exploring and pushing the boundaries, and tell the story to help enlighten folks about what is possible. While I also improve my ability to profile the API space and produce executable API stories that are enabled by Postman.
