Applying An API-First Approach To Understanding The Pacific Northwest Mushroom Industry

This is an API first project for mapping out the mushroom industry. I have always had a passion for mushrooms, but as I get older I am looking at investing in more side projects that aren’t always 100% about APIs. I wanted to spend some time this holidays refreshing my memory about what types of mushrooms are available on the market, and what types of products are being made from them. As I do with any data or content driven research I begin by creating an API to store all of the data and content I am gathering, helping me flesh out the dimensions of each business sector I am interested in.

As with all of my work I really don’t know where this research is headed—I am just interested in learning about mushrooms. Eventually I’d like to use this data and content in a variety of web and mobile applications, but since I’m just getting started I don’t really understand all of the data I am needing to gather. A situation that is perfect suited for beginning as an API first project, helping me not just gather the data I need, but also do it in a way that will help me prepare for the future, while also not investing too much into wiring up a database, coding a web or mobile application, and any other costly infrastructure that may (or may not) be needed down the road. By starting as API first, I am able to flesh out the schema and structure of my APIs which will drive my research, and the resulting applications I will be needing down the road. To get started I spent about 10 minutes thinking about what the main areas of resources I will be needing to track across my work, and created ten separate individual resources.

  • Mushrooms - A list of the mushrooms, their scientific names, description, and the beginning of what I will need to map out the mushroom landscape.
  • Substrates - What the most common substrates for growing mushrooms are, with as much details as I can about how they are used in the industry.
  • Benefits - Documenting what the most common benefits are of eating mushrooms, helping me better understand the market opportunity for each one.
  • Organizations - I needed a way to organize the different companies, organizations, institutions, and government agencies I was coming across in the research.
  • People - There is a need for building out a rolodex of different individual I am talking to, keeping track of their details and the conversations around mushrooms.
  • Recipes - I have been coming across some interesting mushroom recipes and want to be organized in how I document them and make them available in the future.
  • Product Types - I am really curious of the types of products that I am coming across and organizing them into specific buckets helping define the market.
  • Products - I want to make sure I am tracking on specific instances of products from companies, while labeling them by the type of product they are.
  • News - I will be curating interesting news articles that I come across, helping me bookmark relevant news that impacts my research and sends me in new directions, or supports my existing ideas.
  • Industry Sales - There is a wealth of data about the mushroom industry from state and federal government agencies which I am organizing into relevant data sets for inclusion in my research.

Think of each of these resources as a worksheet in a single Microsoft Excel or Google Sheet spreadsheet. Providing me with a place where I can store data in a variety of buckets. Which begs the question, why don’t I just use a spreadsheet? Well, the data is a little more structured than what I can easily accomplish with a spreadsheet. That is a path I may explore for other simpler projects, but I know that my mushroom, substrate, recipes, and product data will most likely end up being more multi-dimensional than a simple spreadsheet will allow. This approach allows me to define all of my core resources as APIs, which I can mock and play with in the context of different applications, eventually settling in on a design that I can use to actually deploy an API.

For my API first mushroom industry research I am using Postman to define the collections, and I am saving the initial data set for each resource as an example, which then can be used to actually mock and document the API—all without having to write any code. Meaning, you can run my mushroom Postman collection in your Postman account, generate a mock, and publish documentation, and be able to actually make calls to each API path and see the data returned as part of each response. This allows me to share my mocked mushroom API with any other stakeholders who might have input on which resources I’m defining, and the underlying schema for each one. They can even go ahead and add any resources they desire, change the underlying schema, and evolve the data as part of the collection either locally, or within the team environment where I have shared the mushroom API collection. Allowing us to collaboratively iterate on the design of the data and content I am collection as part of my mushroom industry API research.

I am going to keep iterating on my mushroom industry API first project, fleshing out my approach to understanding the mushroom industry here in the Pacific Northwest, and eventually beyond. It is something that may never actually become a real API, or if I find enough interesting data out there I may actually publish and begin developing a web and mobile application to make my research more widely available. Right now my list of resources, and the underlying schema is rapidly changing based upon what I am learning. API first projects trhive in this kind of environment, and doing API first within Postman is a very efficient and cost effective way for me to flesh out what this project needs. I don’t have write code, and I can easily publish the mocks and documentation and share with other folks I am talking to about this research. They can actually see what is possible, kick the tires, and provide me with feedback. Once things stabilize somewhat I may even consider developing a simple mock web or mobile application so that I can widen the stakeholders I’m talking to beyond the API community. This is what being API first is all about—helping me rapidly iterate on the projects I am developing, while also still building for many possible futures that I can easily service with one API.

If you are interested in where I am going with this you can engage with my mushroom API work over at GitHub where I am publishing the API definitions, schema, JSON data, and powering the road map with GitHub issues.