Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Path Filtering #38
It answers other concerns about the overall API design surface area being too large, too many paths. Path filtering in the API documentation would all for a default set of paths (ie. orgs, locations, services, search), then mid, and advanced tiers.
This would reduce cognitive load for developers when first getting going, but allow for knowledgeable users to get at a wealth of more advanced or precise search endpoints.
I am suggesting this also to handle future addition of API paths, such as utility ones like schema validators, or possible universal ID, taxonomy, messaging, etc. Additional projects, relevant to, and sometimes part of core spec, but off in separate namespace.
Some way of tagging paths. Going to do this in APIs.json index for site.
So when you land on documentation, you get the core resources
Tag for secondary resources -- everything else.
Allow for other grouping in future.
The goal is to prevent overload for new users, but give advanced uses what they need.
The separation of each project into separate microservices is part of this, how I moved /search into it's own. But within each microservice we can group /paths.
Will have example shortly.