Edge API Core (Common Infrastructure)

Description

Edge APIs:

Edge APIs for Folio are designed to allow external systems to integrate with Folio. These are distinct from the internal APIs used by Folio and implemented though Okapi. It is not recommended that external systems integrate directly with Folio/Okapi APIs.

Edge APIs....

  • do not require external systems to integrate to any of the highly specific and homegrown conventions established and required by Okapi

  • can be created which present a familiar interface to external systems which have already created integration to other ILSes for similar purposes (e.g. RTAC)

  • allow the use of standard API authentication techniques such as APIKeys, OAuth, etc..

  • can provide plans and management features such as: data caps; bandwidth restrictions; etc...

  • are versioned independently of the versioning of internal Folio API modules, allowing greater stability for external integrations.

  • can be a conversion layer to allow support for data formats not natively supported by Folio: (e.g. XML)

  • can implement non-HTTP protocols as needed

  • can provide coarse-grain APIs that aggregate multiple calls to internal Folio (fine-grain) APIs.

  • are compatible with future trends in device integration (e.g. checkout machines) where these are IoT devices

The scope of this feature is the implementation of common infrastructure to all Edge APIs. Specifically, it is an NFR optimization to avoid the code duplication (and inconsistencies) that might occur across various Edge API implementations. It is not a blocker for the implementation of those implementations.

Estimates from stories:

  • UXPROD-354 Authorization support for Edge APIs FE: None BE: Large < 10 days

  • UXPROD-353 Configuration support for Edge APIs FE: Small < 3 days BE: Medium < 5 days

  • UXPROD-352 Edge API Common Infrastructure (APIKey management, policies) FE: None BE: Large < 10 days

Not included in roll-up:

  • UXPROD-322 Edge API (Patron Portal) for Right to Erasure FE: None BE: Medium < 5 days CB: Not counting this one, as it's already counted in UXPROD-291

  • UXPROD-320 Edge API (Patron Portal) for Right to Rectification FE: None BE: Medium < 5 days CB: already included in * UXPROD-290

  • UXPROD-319 Edge API (Patron Portal) to deliver user report FE: None BE: Medium < 5 days CB: already included in * UXPROD-289

Priority

Fix versions

None

Development Team

None

Assignee

Solution Architect

Parent Field Value

None

Parent Status

None

Checklist

hide

TestRail: Results

Activity

Show:

VBarNovember 21, 2018 at 2:21 PM

This feature does not block the implementation of individual Edge APIs.

Cate BoeremaNovember 21, 2018 at 12:33 PM

Per FOLIO team meeting yesterday, this is an NFR and shouldn't be ranked. I will remove the early implementer rankings (all were "go-live"). will adjust the feature description, if needed.

Cate BoeremaOctober 10, 2018 at 8:47 AM

, what would be the impact to Chalmers if this feature was not ready at go-live?

+

VBarSeptember 28, 2018 at 5:26 PM

Yes, it represents the work encapsulated in "edge-common" which is a library/framework with its own repo in GitHub.

Cate BoeremaSeptember 24, 2018 at 7:30 AM

is this feature still needed as a separate work item or is the common infrastructure now being addressed as we implement purpose-built APIs?

Details

Reporter

Front End Estimate

Small < 3 days

Front End Estimator

Back End Estimate

XXL < 30 days

Back End Estimator

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created March 5, 2018 at 5:12 AM
Updated September 15, 2020 at 7:30 PM
TestRail: Cases
TestRail: Runs