As part of a cut-over, we know that the API is baseline. A number of large sites use the API as the foundation for their search. Therefore, we need to re-implement the existing API as-is to make sure those partners experience no interruption.
According to Jim, it is "a little weird."
We are not going to reimplement all of the APIs. There are three.
This is a read-only API, and is no more or less dangerous than any other HTTP server. (Which is to say...)
We're using standard libraries, and it talks to read-only database files (not a live server). Therefore, we have some confidence that this is a good/secure implementation pathway for API implementation.
Process checklist
- [ ] Has a clear story statement
- [ ] Can reasonably be done in a few days (otherwise, split this up!)
- [ ] Shepherds have been identified
- [ ] UX youexes all the things
- [ ] Design designs all the things
- [ ] Engineering engineers all the things
- [ ] Meets acceptance criteria
- [ ] Meets [QASP conditions](https://derisking-guide.18f.gov/qasp/)
- [ ] Presented in a review
- [ ] Includes screenshots or references to artifacts
- [ ] Tagged with the sprint where it was finished
- [ ] Archived
### If there's UI...
- [ ] Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order
- [ ] Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works.
- [ ] Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate.
jadudm
commented
1 week ago
At a glance
In order to have search on my site as a partner I want no change to the API
Acceptance Criteria
We use DRY behavior-driven development wherever possible.
Background
As part of a cut-over, we know that the API is baseline. A number of large sites use the API as the foundation for their search. Therefore, we need to re-implement the existing API as-is to make sure those partners experience no interruption.
According to Jim, it is "a little weird."
We are not going to reimplement all of the APIs. There are three.
resultsAPIhttps://open.gsa.gov/api/searchgov-results/
We need to implement this so that it returns the fundamentals, and anything we don't implement has to return valid, empty results.
clicksAPIin order not to break clients, we need to reimplement this, and have it return empty results until we have data.
https://open.gsa.gov/api/searchgov-clicks/
typeaheadAPIWe think we're going to cut this service. However, it needs to return empty results (again) so as to not break clients.
https://open.gsa.gov/api/searchgov-suggestions/
Security Considerations
Required per CM-4.
This is a read-only API, and is no more or less dangerous than any other HTTP server. (Which is to say...)
We're using standard libraries, and it talks to read-only database files (not a live server). Therefore, we have some confidence that this is a good/secure implementation pathway for API implementation.
Process checklist
- [ ] Has a clear story statement - [ ] Can reasonably be done in a few days (otherwise, split this up!) - [ ] Shepherds have been identified - [ ] UX youexes all the things - [ ] Design designs all the things - [ ] Engineering engineers all the things - [ ] Meets acceptance criteria - [ ] Meets [QASP conditions](https://derisking-guide.18f.gov/qasp/) - [ ] Presented in a review - [ ] Includes screenshots or references to artifacts - [ ] Tagged with the sprint where it was finished - [ ] Archived ### If there's UI... - [ ] Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order - [ ] Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works. - [ ] Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate.