The purpose of this page is to serve as a collection point for high level information about edge APIs.
The role of edge APIs is primarily to fulfill three functions:
- Provide simplified (API key-based) auth mechanism allowing interactions with external systems to perform both auth and business logic in a single API call.
- Provide an isolation layer between external systems and backend FOLIO modules which sometimes (frequently?) make breaking contract changes.
- Provide translations (e.g. json -> xml, etc.) or other adaptations to "bridge the gap" between technologies/protocols/formats/etc. used by external systems and those used by FOLIO.
Edge modules provide a simplified authentication mechanism which allows external systems to integrate with FOLIO w/o needing to be changed. Authentication into FOLIO happens in the following ways:
- password flow - a user provides username and password, and gets back an access (okapi) token. That token is then provided in subsequent calls to FOLIO APIs for entitlement and authorization purposes.
- SAML2.0 - the user authenticates with an Identity provider (IdP), and then gets back an access (OKAPI) token. Again that token is then provided in subsequent calls to FOLIO APIs for entitlement and authorization purposes. (This is a simplified description, but makes the point.)
In both cases, it's a two step process... Step#1, authenticate, Step#2 interact with FOLIO using the token obtained in the first step.
Many legacy systems do not support these auth flows, hence a need for Edge APIs.
It is common for these external systems to support the ability to specify a request header, query argument, etc. when calling the ILS. So API key authentication was a natural fit since the API key can be provided in either of those ways.
Another concern with external system integrations is the API contracts themselves. Breaking API changes are made in FOLIO all the time; the FOLIO community must coordinate those contract changes across development teams/modules/etc.
However, that level of coordination and adjustment is not practical in the case of external systems. Even in the best case it means making configuration adjustments in those external systems. In other cases it might mean making code adjustments in codebases which we don't control or otherwise have access to.
Edge APIs mitigate this problem by serving as an effective isolation layer. The outward-facing contract between external systems and the edge APIs does not change often, and if it does the changes will be backwards compatible. In several cases, these outward-facing contracts are governed by standards bodies and are much more stable by their nature. The contracts on the FOLIO side may change. In this case FOLIO controls both sides of the equation (edge api + backend module).
Finally, edge APIs provide translations, format conversions, or other adaptations to bridge the gap between external systems conventions/technologies/protocols/formats and those used in FOLIO. Not all systems know how to consume FOLIO's messages directly, but do know how to consume some set of well-defined messages.
- RTAC offers up live circulation data to discovery layers in a way that insulates them from internal change to FOLIO APIs
- The GOBI edge module provides a way to place orders in FOLIO with a similar degree of insulation
- NCIP and SIP2 illustrate all three of these points, they have different authentication mechanisms, use non-JSON protocols (XML or text), and provide a standards-oriented way for external systems to perform circulation-related actions in FOLIO
- Z39.50/SRU, though not using the edge module frameworks, also illustrates these points: typically on open Web with no authentication, protocols are either in
the ASN.1/BER message format (Z39.50) or the XML (SRU), and they expose a standard search interface to the outside world.
Multiple frameworks have been developed to aid in the creation of edge APIs. These frameworks handle many of the tasks which need to be performed by almost all edge APIs, thereby reducing the amount of code duplication and making it easier to maintain the edge APIs themselves.
The intent of edge-common is to simplify the implementation of edge APIs by providing much of the boilerplate code shared among these APIs.
The README found at the link above contains general information that applies to many of the edge APIs, including the following topics:
- Dependency management
- API Keys: sources, format and generation
- Institutional users and secure storage of credentials
The edge-common framework has been ported to the "spring" stack (aka the "spring way"). See the README for more information.
A list of existing edge APIs and related information/links.
Edge API to interface with FOLIO for 3rd party discovery services to determine holdings availability.
API Documentation: https://dev.folio.org/reference/api/#edge-rtac
Other wiki documentation: What gets returned in edge-rtac response
Sprint Review 36-39 @ ~1:07:10 (Demo)
Edge API to interface with FOLIO for 3rd party discovery services to allow patrons to perform self-service actions (place holds, renewals, etc)
API Documentation: https://dev.folio.org/reference/api/#edge-patron
Sprint Review 40/41 @ 58:00 (Demo - Account Info)
Sprint Review 42/43 @ 1:13:00 (Demo - Loans/Fees & Fines)
The purpose of this edge API is to bridge the gap between 3rd party purchasing systems/vendors and FOLIO. More specifically, the initial implementation was built with EBSCO's GOBI (Global Online Bibliographic Interface) service in mind, though the aim was to make a general-purpose edge API that will work with other vendors as well.
API Documentation: https://dev.folio.org/reference/api/#edge-orders
Sprint Review 42/43 @ ~1:14:40 (Overview)
Sprint Review 46/47 @ ~20:10 (Demo)
Edge-orders is designed to support multiple vendors. Currently, adding a new vendor requires:
- Writing a vendor-specific module (see above) this is where mapping and translation happens between the vendor and FOLIO (mod-orders). Lookups of things like locations, material-types, organizations, etc. will also happen here.
- Minor changes in edge-orders to handle proper routing of requests to the proper vendor-specific module (e.g. mod-gobi, mod-ebsconet, etc.). There's essentially a decision tree that looks at the "type" query argument in the request and uses that to proxy the request to the appropriate API, e.g. POST /orders?type=GOBI proxies the request to POST /gobi/orders.
- One way to make this easier would be to allow for these type → API mappings to be defined via configuration. See EDGORDERS-TBD.
Edge API for Metadata Harvesting (OAI-PMH Version 2.0)
API Documentation: https://dev.folio.org/reference/api/#edge-oai-pmh
Sprint Review 50/51 @ 16:15
Edge API for SIP2 (Standard Interchange Protocol Version 2.0) integration with a Self Check (SC) station. This edge module is unlike the other edge modules due to the fact that SIP2 uses TCP for message interchange. Once the SC is connected to edge-sip2, SIP2 messages are decoded and translated to existing FOLIO API messages. The FOLIO responses are encoded as SIP2 messages and delivered to the SC. Typically the SC will allow the patron to check out an item, check in an item, place a hold on an item, renew an existing loan and pay fees and fines they owe.
API Documentation: https://dev.folio.org/reference/api/#edge-sip2
The purpose of this module is to expose mod-ncip to external applications/3rd party software. It simply passes requests through to the NCIP module (after the API key is authenticated). It does not contain any other functionality.
API Documentation: https://github.com/folio-org/mod-ncip
API Documentation: https://dev.folio.org/reference/api/#edge-inn-reach
Connecting a CaiaSoft remote storage provider.
API Documentation: https://dev.folio.org/reference/api/#edge-caiasoft
Connecting a Dematic remote storage provider.
API Documentation: https://dev.folio.org/reference/api/#edge-dematic
LMS) such as Sakai and Blackboard (LTI Platforms) to FOLIO via the Learning Tools Interoperability (LTI) Advantage protocol to share the course reserves stored in FOLIO.
API Documentation: https://dev.folio.org/reference/api/#edge-lti-courses
Serves OCLC Connexion requests.
API Documentation: n/a
The APIs above are deployed to the following reference environments:
See https://dev.folio.org/guides/automation/ for additional details
Build from HEAD/master nightly.
Example Request (edge-orders):