May 15, 2018

This document contains information on the obsolescence of RFC 3 - Assessment API.

Summary

The read-only API described in this RFC was envisioned as the companion to the Assessment Outcomes Management API (RFC 8), which was envisioned as a write-optimized API. However, instead of having separate read and write API specifications, the current proposed direction is for a single read/write API via the Assessment Outcomes Management API. Those wishing to implement an API for data out may use the API specifications that are part of the Assessment Outcomes Management API.

History

RFC 3 - Assessment API was proposed as a response to the perceived need for a more bulk-focused API aggregates for read of assessment result data. It followed a similar line of thinking to the Enrollment API in designing for simplified access to data for more batch operations (e.g., nightly syncing).

However, over time it was determined that the level of aggregation in the RFC 3 model — while appealing from the perspective of limiting the number of calls an API client would need to make (e.g., the idea of "one and done" API calls that came out of the Vendor-to-Vendor Special Interest Group) — had other limitations. Notably, such a large aggregation of all data into 2 API resources would not work well for event-based models currently being researched.

For example, small changes to the descriptive text of learning standards — say, simply fixing a typo — could lead to the creation of many events. That is, all API aggregates that included the corrected learning standard would need to be updated, just to receive that small text update. As such, the conclusion was that the RFC 3 data model over-aggregated.

A new model was developed that reduced the aggregation. In that model, the following API resources were to be exposed:

/assessments
/assessmentWithItems
/studentAssessment
/studentAssessmentWithItems
/learningObjectives
/learningStandards

This model was never submitted to the RFC process because it had a marked similarity to the current Assessment Outcomes Management API:

/assessments
/objectiveAssessments
/assessmentItems
/learningObjectives
/studentAssessments

In other words, the redesigned API would offer only minor improvements over the Assessment Outcomes Management API, and those improvements would be mostly around metadata management, which API read clients only need to accomplish once in most cases (transfer of student records is where most effort is spent). As such, the decision was to propose a single read-write API for exchange of assessment data via the Assessment Outcomes Management API.

Note that the concept of a more highly-aggregated model has proven useful elsewhere, such as in the Ed-Fi Enrollment API (RFC 4). The issue with the proposed RFC 3 model is that aggregation does not seem to provide as much value in the assessment data domain.

Current State

Other Alliance community efforts continue to look into more batch modalities over REST APIs, and those efforts could have an impact on future specifications in this area. The principal vehicle for coordinating that dialogue is the Bulk Data Exchange over REST API Special Interest Group. Interested parties are advised to follow this work.