Participants

Agenda

• Query Support
  • Searching: e.g. GET /ed-fi/studentSchoolAssociations?studentUniqueId=ABCXYZ
  • Selectors
  • Paging
• HTTP Status Codes
• Security
  • Authentication
  • Authorization
  • Non-repudiation

Materials

Notes

Query Support

• Removing note about "other operators": no comments / no concerns raised.
• Searching
  • Natural keys: yes, several are using it for retrieving IDs, especially before PUT / DELETE (not storing the POST response for future use)
  • Can different Ed-Fi API's have different query keys? No - at least for the natural keys, need to have standard forms - having variation (e.g. today's ODS/API vs. Meadowlark) would be expensive to handle from an API client application standpoint.
  • Furthermore, when a natural key is merged from multiple resources, how would the API client decide which path to take. Could take any, but why force a decision?
  • Example: 
    
    
    • ODS/API allows
      • ?schoolId=1234
      • ?schoolYear=2023
    • Meadowlark allows
      • ?schoolReference.schoolId=1234 or ?calendarReference.schoolId=1234
      • ?schoolYearTypeReference.schoolYear=2023 or ?calendarReference.schoolYear=2023
  • Conclusion: Meadowlark and other API instances need to conform to ODS/API at least for natural key queries
  • Add support for querying Descriptors
• Selectors
  • In theory could be useful, but not implemented in ODS/API today
  • Can solve with Profiles in ODS/API, but not with Meadowlark right now.
  • No objections raised to removing
• Paging
  • Need to continue supporting LIMIT... OFFSET... where possible
  • The API should be able to limit this to avoid overuse that could cause them database performance problems 
    • Make it a SHOULD not a MUST to allow special situations
  • Would like to have more efficient keyset / cursor based paging. COULD have, gradually introduce and maybe get more strict in the future
• Ordering
  • Proposal to add a COULD or SHOULD have requirement for supporting ordering
    • Need to experiment with both ODS/API and Meadowlark to see what is feasible
    • If "could" only, then find a way to declare availability in version endpoint and/or Open API specification
  • Use same key name as found in the search
  • Also a direction (ASC/DESC), and it needs to be by field if allowing sorting by multiple fields

HTTP Status Codes

• No  concerns expressed about further opening up the status codes

Security

• User-level
  • No objections expressed to removing this language, emphasize that the user interface should further limit for users.
  • Three-legged OAuth
  • User authorization
  • User roles
  • Internal User Authorization
• Authorization
  • Meadowlark's current style is extremely limited, does not allow (for example) an Assessment provider to check and see if a Student (created by SIS) exists.
    • But still need to have some limits, i.e. by educationOrganizationId.
  • Meadowlark style not expected to be useful for states. And even some LEA's use claimsets with some customization.
  • Important to maintain restriction by domain, for example not letting a SIS post to an assessment.
  • External User Authorization - not sure that I'm (StephenF) understanding the implications.
    • I think this is about the client application further restricting the data in ways that the Ed-Fi API can't/won't do. Cleanup the language.
  • Grade Level is another parameter that could be useful for restricting access. Example: an assessment provider only able to access 8th grade students.
• Non-repudiation
  • Need to carefully study if/how this can be achieved in ODS/API 7.0 and in Meadowlark, and make sure there is good documentation around this type of logging.
  • Is there a way to hack it in prior ODS/API?

New Questions

• Case sensitivity: PostgreSQL does not support by default, and you lose something when you enable it.
  • Will bring conversation to the next meeting.
• Statement that SSL is required
  • What about internal only systems?

Next meeting: 2023-09-28

Agenda:

• Strictness
  • JSON payload (already discussed)
  • Time component of a dateTime field
  • URL and query string key case sensitivity
  • Query string value case sensitivity
• Optimistic concurrency via etags
• ODS/API features - which should be mentioned in API standards?
  • Profiles
  • Extensions
  • Change Queries
  • Link
  • XSD files
  • Composites
  • Identity pass-through
• New feature requests
  • Delete by natural key
  • Proposal for ORDER BY