Identification
Are you responding as a...
(Choice)
- Vendor who accesses Ed-Fi API instances?
- Host who manages Ed-Fi API instances?
- Education Agency who relies on an Ed-Fi API?
Feature Usage
Which of these ODS/API features do you use?
(Likert scale with options: not used, some usage, critical usage)
- Profiles - for restricting data access
- Both read and write
- Profiles - for performance benefit
- There are fewer attributes in the GET request
- Extensions
- Change Queries
- "Link" in the HTTP response
- PUT requests - instead of DELETE & POST
Some organizations choose to DELETE and then re-POST modified records, instead of using PUT. Commonly this is to avoid extra coding logic around disallowed natural key updates (e.g. no updating a StudentUniqueId).
- ETags and If-Match header
- Data model information list at /api
- XSD endpoint
- Dependencies endpoint
- Enrollment Composite
- Identity Pass-through
- Location header - storing the ID
Strictness
How important are the following to you?
(Likert scale with options: could, should, must)
- Strict JSON payload validation
- e.g. reject extra properties
- Why? Someone might have a typo on an optional property and never realize because it was accepted but thrown away
- e.g. reject extra properties
- Require a DateTime to include the time
- Most validators require the time component, though some systems will infer it as midnight
- Store time in UTC
- Otherwise, whose timezone is it?
- Resources names and attributes are case sensitive
- /ed-fi/classPeriods is different from /ed-fi/ClAsPeriODs
- ?schoolId=1234 is a valid query but ?sCHOoLid=1234 is not.
- Strings (e.g. in payload, or search values) are case sensitive
- ?firstName=John and ?firstName=JOHN return different results
- This is the default in PostgreSQL, but not in SQL Server
- Modifying the database setting is harder than one would think
- API version metadata declares case sensitivity
- New idea for future releases
- New idea for future releases