Edge API Core (Common Infrastructure) (UXPROD-994)

[UXPROD-347] Edge API Core (Common Infrastructure) Created: 05/Mar/18  Updated: 15/Sep/20

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Edge API Core (Common Infrastructure)

Type: New Feature Priority: P3
Reporter: VBar Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: NFR, edgeapi, external_sys_int, suppress-from-capplan
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks UXPROD-319 Edge API (Patron Portal) to deliver u... Open
blocks UXPROD-320 Edge API (Patron Portal) for Right to... Open
blocks UXPROD-322 Edge API (Patron Portal) for Right to... Open
blocks UXPROD-326 Edge API (Patron Portal) to deliver p... Open
Cloners
is cloned by UXPROD-994 Edge API Core (Common Infrastructure) Closed
Relates
relates to UXPROD-352 Edge API Common Infrastructure (APIKe... Open
relates to UXPROD-353 Configuration support for Edge APIs Open
relates to UXPROD-354 Authorization support for Edge APIs Open
Epic Link: Edge API Core (Common Infrastructure)
Front End Estimate: Small < 3 days
Front End Estimator: VBar
Back End Estimate: XXL < 30 days
Back End Estimator: VBar

 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 Open Authorization support for Edge APIs FE: None BE: Large < 10 days
  • UXPROD-353 Open Configuration support for Edge APIs FE: Small < 3 days BE: Medium < 5 days
  • UXPROD-352 Open Edge API Common Infrastructure (APIKey management, policies) FE: None BE: Large < 10 days

Not included in roll-up:

  • UXPROD-322 Open 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 Open
  • UXPROD-320 Open Edge API (Patron Portal) for Right to Rectification FE: None BE: Medium < 5 days CB: already included in * UXPROD-290 Open
  • UXPROD-319 Open Edge API (Patron Portal) to deliver user report FE: None BE: Medium < 5 days CB: already included in * UXPROD-289 Open


 Comments   
Comment by Cate Boerema (Inactive) [ 26/Apr/18 ]

VBar, I need to tag this with a project. Is it Analytics, GDPR, something else?

Comment by VBar [ 26/Apr/18 ]

This is something that stands apart from all those. "Edge API" should be its own project in exactly the same way that Stripes is its own project - it is an alternative to Stripes.

Comment by Cate Boerema (Inactive) [ 09/Jul/18 ]

Changing all the external system integration features into epics. While this will extend the epic list by 7 items, these really are all mini-projects that can be assigned to teams and have POs and priorities. In that regard, they make sense as epics. I will deprecate the old External Systems Integrations epic.

Comment by Cate Boerema (Inactive) [ 09/Jul/18 ]

Actually, I should leave these as features and clone them to create epics. I will change this back to a feature and associate it with this new, cloned epic: UXPROD-994 Closed

Comment by Cate Boerema (Inactive) [ 24/Sep/18 ]

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

Comment by VBar [ 28/Sep/18 ]

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

Comment by Cate Boerema (Inactive) [ 10/Oct/18 ]

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

+ Theodor Tolstoy (One-Group.se)

Comment by Cate Boerema (Inactive) [ 21/Nov/18 ]

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"). VBar will adjust the feature description, if needed.

Comment by VBar [ 21/Nov/18 ]

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

Generated at Fri Feb 09 00:07:30 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.