Skip to content
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

Add API client identification and versioning to all GOlr calls #1

Open
kltm opened this issue Aug 9, 2016 · 1 comment
Open

Add API client identification and versioning to all GOlr calls #1

kltm opened this issue Aug 9, 2016 · 1 comment

Comments

@kltm
Copy link
Member

kltm commented Aug 9, 2016

As more work gets sent to the GOlr backend via API calls (e.g. embedded JS clients in AmiGO), the majority of user interaction is flying below the radar. For example, once a user reaches a search page, what are they searching for. As well, is there a difference between what AmiGO users are doing and JS API (e.g. Planteome) users are doing? We currently have no tools to track usage of the GOlr API directly, which will soon be the dominant use case.

To help solve this problem, all published APIs should use their package name and version as a default value to the overrideable and round-tripping variables agent-name and agent-version. If somebody makes a derivative API, or is using the API for a specific task, they should be encouraged to override this with their agent name and version. For example, production GO AmiGO could use amigo-production and 2.4.40 instead of bbop-manager-golr and 1.14. It might be good to also add a variable agent-activity, for things like search, matrix, information to further sub-divide.

Also, in this way, if somebody is making direct naked calls to the API, that can still be detected as they will be the only ones not using the desired variable (and could be blocked).

Thinking ahead, in case we got too popular, it gives us a path forward if we wish to enforce limitations by API key or other mechanisms.

@kltm
Copy link
Member Author

kltm commented Aug 9, 2016

Part of this would involve making sure that the default logging capabilities were available in the new Solr 6 rollouts that we're planning. Will talk to @jnguyenx about that later on.

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

No branches or pull requests

1 participant