You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the issue
The API endpoint that returns controlled vocabulary results and autosuggest results are served by a single end point. These should be decoupled into domain-specific endpoints to reduce complexity of the current single endpoint, e.g. accounting for site-wide vs. journal specific results, etc.
I think the only place this function is used is in the vocabs API controller, which is where the front end gets autosuggest possibilities. I think having a single endpoint for all vocab suggestions is actually the mistake -- it leads to the need for a single point of access for vocabs that might be attached to many different things, so we have to hard-code all the checks to make sure the list is allowed into a single place.
Instead, I suggest we break the endpoints where autosuggest responses are built into the appropriate places in the API. Autosuggestions for reviewer interests, which are global, should not be attached to the same endpoint as autosuggest results for article keywords, which are (probably) journal-specific.
@ewhanson, can we revisit the controlled vocab API handler? I don't think a single endpoint is the right design.
Describe the issue
The API endpoint that returns controlled vocabulary results and autosuggest results are served by a single end point. These should be decoupled into domain-specific endpoints to reduce complexity of the current single endpoint, e.g. accounting for site-wide vs. journal specific results, etc.
Current context
From @asmecher, in the context of #10324 (comment).
Code reference from
ControlledVocab.php
:** TODO **
The text was updated successfully, but these errors were encountered: