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

🔌 re-implement existing API #33

Open
1 task
jadudm opened this issue Nov 23, 2024 · 1 comment
Open
1 task

🔌 re-implement existing API #33

jadudm opened this issue Nov 23, 2024 · 1 comment

Comments

@jadudm
Copy link
Collaborator

jadudm commented Nov 23, 2024

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.

then...

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.

results API

https://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.

clicks API

in 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/

typeahead API

We 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
  • 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 jadudm added this to jemison Nov 23, 2024
@github-project-automation github-project-automation bot moved this to triage in jemison Nov 23, 2024
@jadudm jadudm moved this from triage to backlog in jemison Nov 23, 2024
@jadudm
Copy link
Collaborator Author

jadudm commented Nov 24, 2024

Related to #38.

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

No branches or pull requests

1 participant