...

• 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" link  in the HTTP response
  
• PUT requests - instead of DELETE & POST
  • Some organizations choose to DELETE and   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  header
  
• Data model information list at /api
  
• XSD endpoint
  
• Dependencies endpoint
  
• Enrollment Composite
• Identity Pass-through
• Location header - storing the ID
  

...

How important are the following to you as requirements for an Ed-Fi API?

(Likert scale with options: must not, 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
• 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 Case sensitive 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  is not.
  Strings (e.g. in payload, or search values) are case sensitive
  • Should not be (or not only) dependent on database technology
• Case sensitive string values
  
  • ?firstName=John and ?firstName=JOHN return   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

Proposals

How important are the following to you as requirements for an Ed-Fi API?

(Likert scale with options: must not, could, should, must)

• Declare case sensitivity in metadata
  
  • New idea for future releases
    
• Delete by natural key
  • e.g. instead of DELETE .. /ed-fi/students/abcd1234xyz then DELETE ../ed-fi/students/studentUniqueId=1234
  • Particularly useful for organizations who are not storing the Ed-Fi unique identifier (abcd1234xyz in the example above).