Package: okapi Architecture: all Version: 1.2.4+SNAPSHOT20170407211423-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 49976 Depends: openjdk-8-jdk | openjdk-8-jre, adduser, postgresql-client-common Filename: testing/okapi_1.2.4+SNAPSHOT20170407211423-1_all.deb Size: 21446946 MD5sum: 7ac3ac9d5e7d63b14845322994697777 SHA1: f6396c664012ab86edd3ab0fa46356e14ac6a4f6 SHA256: 957b3fb779446c84fd0317303126ba0230a65e7504b5f0502fcbcbfc496e2dfb SHA512: 4ad649189a50ae4b4a0e2ab8d6849fb54b992a1a7c199031365b15015aad559c78f74bdbd90f75c5889b9efc6354efda746fe127911a2ba8fd904cc8af3ed6b7 Homepage: https://github.com/folio-org/okapi Description: Multitenant API gateway for FOLIO Okapi is an implementation of some different patterns commonly used within the microservice architecture. The most central of them is the so called "API Gateway" pattern which is implemented by the core Okapi 'proxy' service. Conceptually, the API Gateway is a server that is a single entry point into the system. It is similar to the Facade pattern from object-oriented design. Per the standard definition, which Okapi follows quite closely, the API Gateway encapsulates the internal system architecture and provides a unified API that may be tailored to each client; it might also include core responsibilities such as authentication, monitoring, load balancing, caching, request shaping and management, and static response handling: from the Message Queue design pattern to allow broadcasting of requests to multiple services (initially synchronously and eventually, possibly, asynchronously) and returning a final response. Finally, Okapi facilitates communication between services by acting as a Service Discovery tool: service A wanting to talk to service B only needs to know its HTTP interface since Okapi will inspect the registry of available services to locate the physical instance of the service.