What Is My API Network

I am working on the vision for the Postman Network. As I do with everything, I want to start with the basics human aspects of what is going on, and then relate them to the more technical and then business aspects of it all. Right now, the Postman Network is a listing of teams and individuals who have published Postman collections under a handful of categories. While visiting the network you can browse collections by category or search by keyword, and view the team or individual profile, select the “Run in Postman” button, or view the documentation. My goal is to brainstorm what is next for the Postman network, but also help define what network means in a world of API collaboration.

When it comes to my API network, I like to focus on the meaningful elements, the “person, place, or thing” that makes my world go around. I am not interested in nouns that do not enrich my world, and I am keen on emphasis of the humanity of all of this over purely the tech for the sake of tech. So what are the nouns that make up my world?

  • People - While I don’t always like people, because I am one, they tend to be the center of my world. People are the most important building block of my network, and drive what I truly care about when it comes to APIs.
  • Teams - I engage with a variety of teams as part of my job, both internal to Postman, but also externally across the many different enterprise organizations I am working with. While I have relationships with individuals on the team, I find myself regularly thinking about how to add value to the entire team, and influence how and why they are doing APIs.
  • Projects - My world is littered with projects. Some projects move forward, while others simmer, and sometimes whither on the vine. Projects usually involve one or many APIs, as well as one or many people. While people are the center of my world, my network is usually in service of moving a specific project forward with a specific purpose in mind.
  • Workspaces - There are a number of places where I get work one. These include, but are not limited to local folders, cloud folders, repositories, and other constructs that help me organize the artifacts that are most important to my network. These are the places where my network meats and gets work done on a regular basis. 
  • Specifications - There are a handful of API and data specifications that rule my world, and define my network. OpenAPI, JSON Schema, Postman, are a few of the specifications that define how I communicate, collaborate, and interact with my network in a human as well as machine readable way, helping me automate and govern how I do what Id o on a daily basis. 
  • Definitions - From the specifications I use I produce a wealth of definitions that reflect specific projects and APIs I am working on. These definitions are the life blood of my network, helping me articulate some pretty abstract concepts to the people in my network, helping me move forward a variety of projects with different objectives.
  • Organizations - The people I engage with are always part of a larger organization. While they tend to have their own personalities, an team or project objective, they belong to a larger organization and have the vision and brand of that organization to consider—something that always influences how I network with them.
  • Domains - One of the defining areas of my world are domains. Not just areas of knowledge, but actual online domains governed by DNS. These tend to go hand in hand and reflect the different areas of work that are occurring across my network, and provide the bounded context for how I conduct work and publish the result of that work. 
  • Industries - Since my network has such a large public face to it, there are many considerations for the industries I am targeting with specific APIs, messages, and storytelling. This is the 100K view of my network, allowing me to see things at the highest level, spanning my individuals, teams, specifications, definitions, and organizations.

I am ending the noun discussion there, although I am going to continue describing many more in the coming section, but I’d say these are closer to the meaningful network actions I’m looking to highlight than the actual person, place, or thing that are central. These are many of the actions I am thinking about when it comes to what occurs across my network. The things that make it a living, active, and useful network to many people, teams, and organizations.

  • Create - How I create teams, projects, workspaces, definitions, and relate those to organizations, domains, industries, and people.
  • Message - I need to send public and private messages to people on my network about the different areas of operation.
  • Comment - Beyond basic messaging I need to leave comments in different areas of my network, providing more context to stakeholders.
  • Annotate - I also need to add specific details to individual objects, or pieces of objects that exist across my network.
  • Questions - I need to be able to ask questions, as well as answer questions from others on my network.
  • Invites - I will need to be able to invite people to different teams, projects, workspaces, and other contexts of my network.
  • Roles - I need to apply roles to different people who participate in activity across my network, governing who is able to do what.
  • Relationship - Establish the connection between people, teams, and organizations across my network spheres. 
  • Mentor - I will need to mentor some individuals on my network when it comes to projects, specifications, definitions, and other concepts.
  • Edits - Everything on my network will need editing, allowing me to perpetually changing the core element I am moving forward.
  • Publish - Specifications and definitions need regular publishing to workspaces, domains, and other dimensions of my network.
  • Version - Artifacts all need to be versioned, allowing them to be evolved, helping manage both major, minor, and fixes to objects.
  • Fork - Artifacts need to be forked, allowing derivatives to be established and evolved separate from the core definition.
  • Merge - Any artifacts that have been merged need to also have the ability to be merged back into the master version of each definition.
  • Search - Any element on my network should be searchable, allowing me to find what is going on across every network element.
  • Sync - Artifacts and the activity around them should be sinkable to other workspaces, organizations, and areas they are needed.
  • Integrate - I want to be able to expand my network by integrating different aspects of it to other platforms and systems using APIs.
  • Issues - I want to be able to report, identify, and work with issues in context of different artifacts and elements of my network.
  • Share - Everything on my network should be able to be shared with users, with a consideration for what should be public or private.
  • Browse - I should be able to browse my network, and explore what is happening across teams, workspaces, and other elements.
  • Notify - I should be able to tune into or tune out of notifications around events that are occurring across my network.
  • Script - There should be opportunities for scripting to help me automate, orchestrate, and work with different elements of my network.
  • Run - I should able to run scripts, definitions, and other elements of my network, providing me with a runtime layer to my network.
  • Store - I should be able to store data as part of my network operations, organizing the exhaust and output from network operations.
  • Monitor - I should be able to monitor any aspect of what is happening across my network, allowing me to tune into what is going on.
  • Test - I want to be able to create, manage, execute, and report upon tests established as part of artifacts on my network.
  • Automate - I should be able to schedule and automate how and when things run on my network, expanding on what I am capable of.
  • Validate - There should be mechanisms for me to validate specifications, definitions, and data in motion across my network.
  • Document - I want to be able to document different aspects of my network, publishing a view of each area for others to consume.
  • History - There should be a history of everything that is occurring across my network, allowing for observability into network operations.
  • Activity - History should be able to be seen as it is happening, allowing for visibility into events that are occurring across my network.
  • Analyze - I want to be able to analyze and report upon what is happening across the network, at the highest and lowest levels.
  • Visualize - I want to be able to visualize the outputs from various aspects of my network, and see what is going on in different places.
  • Observe - I want to have observability across my network, consistently providing me visibility into everything that is happening.
  • Duplicate - Artifacts and other elements should be able to be duplicated, allowing for easy replication across my network.
  • Mock - I want to be able to mock interfaces and data that is in motion across my network, and share as a mock interface.
  • Import - Artifacts should be able to be imported into different areas of my network, allowing me to easily bring in new artifacts.
  • Export - Artifacts should also be able to be exported from different areas of my network, allowing me to easily get artifacts out.
  • Remove - I should be able to remove any part of my network, allowing me to curate my network as I see fit, across every area.

There are several actions here that clearly have objects associated with them, but my intend here is to understand what they enable, and what action is being taken as part of my network—not be hard about what is a noun vs verb. I see my network as made up of people, teams, projects, workspaces, specifications, definitions, organizations, domains, and industries. These are the defining lines of my network, and this list of actions I take will produce data, content, and other artifacts as part of my network, but they provide me with a way to map out the intent, incentives, and meaningful value that gets delivered across my network. These are the things that make my network remain viable and something that helps me accomplish what I am looking to do as a professional within an organization, and across multiple industries. 

Across my network, things like code are rapidly becoming more ephemeral. In a serverless, runtime, test-driven wold, code is becoming lighter weight, and act as ephemeral gears throughout my network. Something that is easily replace and removed as needed, acting much like mocks, docs, and other elements of operations. Scripting is more of an action, then an actual thing. Specifications and definitions are the most meaningful constant, actions being taken against them by people across many different projects, workspaces, organizations, domains, and industries. This is an initial attempt at quantifying my network so that I can provide more coherent and thoughtful feedback on how other people define their own networks, helping drive a variety of conversations I am in when it comes to how we structure our operations. This is my view of my network, but the building blocks provide me with some lego blocks I can use when mapping out the landscape of other networks I’m providing input on. Hopefully influencing the future of the Postman network, as well as the other enterprise organizations i am working with.