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: 
    
    

    Open

    

    
    
    

    • 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