New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path Filtering #38

Open
kinlane opened this Issue Jul 9, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@kinlane
Contributor

kinlane commented Jul 9, 2017

I'm opening up a 3rd dimension to the whole filtering conversation. It is relevatng data filtering (#22) and schema filtering (#21), but is at a higher level.

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.

@kinlane kinlane added the road map label Jul 9, 2017

@NeilMcKechnie

This comment has been minimized.

Show comment
Hide comment
@NeilMcKechnie

NeilMcKechnie Aug 10, 2017

Thanks @kinlane but I'm not sure what exactly you are asking for here, can you clarify please?

NeilMcKechnie commented Aug 10, 2017

Thanks @kinlane but I'm not sure what exactly you are asking for here, can you clarify please?

@kinlane

This comment has been minimized.

Show comment
Hide comment
@kinlane

kinlane Sep 1, 2017

Contributor

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

/organizations
/locations
/services

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.

Contributor

kinlane commented Sep 1, 2017

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

/organizations
/locations
/services

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.

@kinlane kinlane removed the road map label Sep 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment