Chooser
Legacy
| Area | resolution |
| Language | Python |
| Description | Display page for multiple-resolution and co-access |
| Production URLs | |
| Production Heartbeats | |
| Documentation | [http://gitlab.com/crossref/chooser] |
| Quality | Sentry, no SONAR |
| Source Code | |
| Products |
“Chooser” is a FastAPI application written in Python that performs the following functions:
- Presents options, with clearbit logos, for multiple resolution items
- Presents options, with clearbit logos, for co-access items
The HANDLE system determines whether an item should be routed to internal systems, as per the “redirect sequence”, below.
Redirect Sequence
How does HANDLE know to redirect MR/Co-access requests to the internal Crossref system? Because the CS system intercepts deposits that are multiple resolution or coaccess and points them to iPage at the time of deposit.
Incoming DOI/HANDLE request points the DOI to http://www.crossref.org/iPage?doi=10.XXXX which in turn rewrites to Chooser with the DC HAProxy redirecting these iPage requests to Chooser. Requests to coaccess (apps.crossref.org/coaccess) or multiple resolution (doi.crossref.org/iPage / mr.crossref.org / *.crossref.org/iPage) get redirected to Chooser.
Data Sources
The Chooser interface makes calls to two separate data sources:
- The REST API to gather metadata about the current item;
- and the Clearbit service to gather logos for off-site links
Error Handling
Chooser uses Sentry for debugging and error handling. Until May 2024 the most frequent cause of failure was a timeout on Clearbit logo resolution. Now the most frequent error is a retry error that occurs in sync with failures of the REST API.
