search

berkeleybop / bbop-manager-golr

Manager for handling communication and callbacks with GOlr instances.
BSD 3-Clause "New" or "Revised" License
0 stars 1 forks source link

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

Open kltm opened 8 years ago

kltm commented 8 years ago

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 commented 8 years ago

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.