The purpose of this page is to serve as a collection point for high level information about edge APIs.
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
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.
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):