Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 9 Next »

Overview

Implementers of Ed-Fi technology have signaled the need for an administrative API (Admin API) to automate functions such as key/secret management, application management and other key functions.  Automated deployments are becoming more of a trend throughout Ed-Fi technology stack deployments.  An Admin API would enable implementers to automate functions that require manual efforts today.  

Ed-Fi's Admin App is an application that provides a user-interface (UI) to some of these functions and will be a basis for Admin API initial functionality.  Admin App provides business logic and a user-interface to necessary functions such as credentials, application, vendor and claim set management.  The Admin API will leverage the pre-existing and reviewed business logic created in Admin App as a basis of an initial release, however the Admin API would be expected to grow in functionality as requirements are identified by the Ed-Fi community.

This page proposes a design of an Admin API component.  

A related epic in Ed-Fi Tracker is available for this effort via AA-1442 - Getting issue details... STATUS .

Use Cases

The Admin API will be called programmatically within automated deployment environments.  A knowledgeable person or team of people with IT administrative functions will be responsible for the configuration, usage and security of the Admin API.  The Admin API will automate functions currently done today via custom scripting and/or human intervention via a user-interface, such as the  Admin App or other management interfaces.

Functional Requirements

Below are functional requirements for an Admin API to automate and manage an Ed-Fi Technology Stack.

Deployment

The Admin API is a standalone component and will not require the Admin App to run. Some early adopters may opt to install both applications side-by-side, as the MVP of Admin API will not be feature-complete when compared to the existing Web UI.

The primary target deployment for Admin API is most requested in Docker-automated environments. Due to the implementation of our Docker images, hosting on IIS will be straightforward using IIS, although will not automated with an installer until after MVP.

Authentication

The Admin API must allow for secure, trusted communication via API.  Compared to Admin Web UI, the Admin API will run as a "superuser" capacity as a delegated IT administrator with responsibilities of managing a secure environment.  Multiple and role-based consumers may be introduced for future API endpoints, but for initial release, a single set of credentials would be acceptable. 

API Endpoints

Below are suggested API endpoints to implement the primary use cases as mentioned above.

NOTE:  need to address multi-instance in the API endpoint

API EndpointSupported OperationsFunctionRequest PayloadResponse Content
/admin/identity/connect/tokenPOSTLogin to retrieve a token for authorized Admin API usage.
POST:  201 (Created)
ALL: 401 (Unauthorized), 500 (System Error)
/admin/identity/api/clientPOSTCreate a new identity for Admin API usage.
POST:  201 (Created)
ALL: 401 (Unauthorized), 500 (System Error)
/admin/vendorsGETRetrieve listing of existing vendorsN/A

GET:  200 (OK)
POST:  201 (Created)
ALL: 401 (Unauthorized), 500 (System Error)

POSTAdd a new vendor.

/admin/vendors/{id}GETRetrieve detail information for an existing vendorN/A

GET:  204 (OK)
PUT:  204 (No Content / Updated)
DELETE: 200 (OK)
ALL: 401 (Unauthorized), 500 (System Error)

PUTUpdate vendor information

DELETEDelete a vendor

/admin/claimsetsGETReturns list of valid claimsets available in the system (needed for defining applications)N/A
/admin/applicationsGETRetrieve listing of existing applicationsN/A
POSTCreate a new application.
GET:  200 (OK)
POST:  201 (Created)
ALL: 401 (Unauthorized), 500 (System Error)
/admin/applications/{id}GET Retrieve detail information for an existing application.  Update application information.  Delete a application.N/A

GET:  200 (OK)
PUT:  204 (No Content / Updated)
DELETE: 200 (OK)
ALL: 401 (Unauthorized), 500 (System Error)

PUT


DELETE


/admin/applications/{id}/reset-credentialPUTReset application credentialN/A200 OK (Application ID, Key, Secret, API Url)

Response Structure

API responses are "wrapped" in a common format to ease client interpretation and ingestion.

Common Responses

The following API responses are common between endpoints and will utilize a standard response structure around the content that varies.

Response CodeValid VerbsDescriptionStructure
400 Bad RequestPOST, PUT, DELETEProblem with request body (validation issue or incorrect use)
401 UnauthorizedAllBearer token is missing or invalid
500 Internal Server ErrorAllUnexpected error has occurred

Technical Requirements

Below are technical requirements for the Admin API:

Solution Design

Admin API will be implemented as a new .NET 6 'minimal' API project in the current ODS-Tools solution and repository. While it will share logic with the current Web UI, it will be a separate application.

The ODS-Tools solution currently includes a layer of abstraction around business logic in the form of the EdFi.Ods.AdminApp.Management  library. Rather than further abstract the functional logic in Admin App, the API project will utilize this code library, including introducing new API-scoped implementations for model interfaces that may differ from similar functions in the existing Web. The Management library, like the Web UI, currently targets .NET 3.1. In order to safely enable side-by-side implementation, the library (and its installation-specific counterparts) will be changed to target .NET Standard 2.1, which is compatible with both .NET Core 3.1 and .NET 6.

Testing

Absent from the above diagram are automated test projects. The existing app functionality in AdminApp.Management  is well-covered by unit and integration tests. Rather than doubling down on those, we will plan on introducing end-to-end tests using Cucumber or PostMan automation to verify the API's response for different scenarios.

Authentication and Authorization

  • Hints at authentication/authorization — Data Import TSS copy over would be fine, or updates from that good too

Authorization


Authentication


Logging

Documentation

Hosting and Deployment

  • Hints at deployment requirements for Admin API standalone in Docker and Windows configs.  (Docker the focus)

Source Code

The Admin API will be released as Apache 2.0 source code, as with Ed-Fi's ODS/API Platform and Admin App. 





  • No labels