Currently we use api.data.gov and ReVal (imls-validation) to 1. secure API access and 2. validate incoming data to the database.
For phase 4, I think we want to remove both dependencies as these are fairly heavyweight. I think we can build a validation layer on top of Directus, perhaps entirely using SQL triggers. And since we are automatically handing out authentication tokens via a separate service, I think we can layer on authentication (and perhaps some rough rate limiting, e.g., 429 Too Many Requests).
This covers the following stories:
Authentication
Validation (server-side)
This ticket may need to be further subdivided; this is a placeholder issue for now.
As an ...
We'll know we're done when...
[ ] When a user can ...
Tasks
[ ] Design designs all the things
[ ] Engineering engineers all the things
Definition of Done
[ ] Meets technical definition of done
[ ] Meets acceptance criteria
[ ] PO approved
[ ] Usability tested
[ ] FE test suite updated to test the form
[ ] API test suite updated to demonstrate functionality, correctness.
[ ] Rough draft of support documentation ("exists" not "perfect").
Background
Currently we use api.data.gov and ReVal (
imls-validation
) to 1. secure API access and 2. validate incoming data to the database.For phase 4, I think we want to remove both dependencies as these are fairly heavyweight. I think we can build a validation layer on top of Directus, perhaps entirely using SQL triggers. And since we are automatically handing out authentication tokens via a separate service, I think we can layer on authentication (and perhaps some rough rate limiting, e.g., 429
Too Many Requests
).This covers the following stories:
We'll know we're done when...
Tasks
Definition of Done