Clarification (simplification) of tool categories

[karelhusa]

User Story

As a user, I need to orient in tool categories quickly. Currently, some categories are synonymous. Some categories are fine-grained (such as data validators), while others are coarse (Server, Security, Testing).

As a tool provider, I want to know which category to pick or which to check if my product is already listed.

Detailed Requirement

I would suggest setting categories according to API lifecycle phases plus Security and Learning, which relates to all of them:

• Design
• Mocking / Virtualization
• Implementation
• Testing
• Documentation
• Deployment / Runtime
• Security
• Learning

Maybe the "Use Case Area" (or an apter word) would describe the categories best.

[SensibleWood]

@karelhusa Makes perfect sense - good shout. Currently we are showing the raw data from source, but we can reclassify and use that data as a seed for the Bayesian analysis to then slot data into the right place. I guess there is actually a matrix view here i.e. what does a tool do vs. when does a developer use that too to do "something".

[philsturgeon]

Yeah I'd add to that @SensibleWood and say I use lots of tools can be used in multiple stages of the lifecycle, and all the tools that are used in a single stage might have nothing in common with each other.

During the design process I am using a Visual Editor like Stoplight Studio, getting linting feedback as I design from Spectral, and trying out my mocks real time with Prism to see if I like the way it works. They should not all be in the same category as they are all very different tools.

Also I would not know where to find e.g.: linting tools in this list.

[karelhusa]

@philsturgeon, I understand that I can employ the Mocking/Virtualization tool in:

• API design (to verify design),
• API testing (to design tests),
• API development (develop against mocks),
• deployment (test against mocks in the pipeline)
• documentation (try on mocks), etc.
  But still, a tool with a Mocking function (e.g., MockServer, ReadyAPI, Postman) would belong to the Mocking/Virtualization category. ReadyAPI would fit in Testing as well, but not Design. Postman would also come to Design, Testing, Documentation, etc. MockServer would go only in the Mocking/Virtualization category.

The API phases have their relations but are still well defined and have clear boundaries. OpenAPI linting tools would come to API design because it's validating the design. However, I can use a linter in Testing to validate the design. Maybe the word "phase" is misleading because we think about "use case areas," not sequential phases.

I like the @SensibleWood matrix suggestion.

Another benefit of Tool - Phase relation would be that you can display the tool detail and see which phases it relates to.