SoT: API

[jadudm]

Problem

With the SoT introduction, we could end up with a picture that looks like this:

Submission ───────► SAC ────────► Dissemination────► API 1.1.0
     │                                                        
     │                                                        
     └───────────► SoT ─────────► API 2.0

The goal is to ultimately eliminate the SAC/1.1.0 path way, and leave only SoT/2.0, where we would rename "2.0" down to 1.1.0, providing zero interruption in service to partners. The 2.0 API should produce the exact same data, for all endpoints, as 1.1.0.

How did we discover this problem?

Job Story(s)

When I [situation], I want to [motivation] so I can [outcome/benefit].

What are we planning to do about it?

What are we not planning to do about it?

How will we measure success?

Security Considerations

Required per CM-4.

---

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.