Package: okapi Architecture: all Version: 4.14.9-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 64053 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.9-1_all.deb Size: 58645692 MD5sum: b2f3809ab2307885b651b7acbc93e69e SHA1: e12f158dea51bf4d848fee8a19159e6ae3e96142 SHA256: ee000176e9aeff25a8aa0e2996b83693a7b43a087af3b112c1efa445da3b43d1 SHA512: 596ec38d5c3b49cebb7187b90b2c89a01c40b7f78829a92727dcd5aa88e2669111fe39bf29df7697e607552c43a43e45350075968710b946555f707e3b9897d6 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. Package: okapi Architecture: all Version: 4.13.3-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62718 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.13.3-1_all.deb Size: 54283136 MD5sum: 5daaac270a386882095fedb7fef0134b SHA1: fe23718ea4a7bc8f8c4a48beb97f2e3760e2d76f SHA256: 2f286e55d8540df021607f8aa750db4322fe702ec2ed0512e23c27eef8d1972f SHA512: 6ce26ecb7319dffd85198d956af547d76ed2b3790fb0011d5e2028cf8d1e655cdd33e5c16e5183da080ca142c503d343138e2ba064749e6e24c69f4535c56022 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. Package: okapi Architecture: all Version: 4.3.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 67766 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.3.1-1_all.deb Size: 60355856 MD5sum: 712ede4a26dc13acf56d4c01e8f72096 SHA1: 194eff206ec69b07fc5d30646306231c0ff3d281 SHA256: d029c1d43d1ae495d2e860921652177fcf3ef53fef5bd80bf03ba034b53dcfbd SHA512: 5670da5beb0c8af9640ee916af9aa0491845d50dde40de821b16e43d4b768a473b12753ca77b75a4b53272ccc4390adaeaf152e7d67aaafb6dafea09f5573d59 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. Package: okapi Architecture: all Version: 4.14.8-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 64019 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.8-1_all.deb Size: 58609160 MD5sum: bf6f0adff0bae3a583f43eb361e70a24 SHA1: 9b1c24ac33f2662884139ae8990f6fcc55bdd0c8 SHA256: 0b3f1aef247b35917494beb528e753fb2813fc25d29bc02eb8edf7adb243ce1e SHA512: d063a78e0a991868b3472787bb56045fe7ef4a5295dd634c795d25fef8d1281eb841b5346b1a8e89488657ca90a6f1af74b699eb3dd9b2180abd01618eb44e2c 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. Package: okapi Architecture: all Version: 4.4.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68047 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.4.2-1_all.deb Size: 60608188 MD5sum: 5001f1c93b5a83f9e04a7d7163945e5d SHA1: 69084625d2f3a2f120f71fdb5ba96e6df555bf7e SHA256: 0e00892eb97c77328aca40ab5ed5701a0ddcea3bd3cf774247ddd8d429421839 SHA512: 3544ca2b6c22d974a2eaa2e2c7f79d1f7b612558b174593ab938a6fe3af1abb8fc507e5137e371161fbef71f35c0d0a8edebf5cde8daf4cceac955cd5cf953bb 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. Package: okapi Architecture: all Version: 4.7.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 69371 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.7.0-1_all.deb Size: 61877980 MD5sum: a3433c52db2deeb6337fa502cb3c7e78 SHA1: 730cf008d880ca83fbc4bf187a2bde3e9ac057ba SHA256: 459b722146852ca11cdd6d87784b6014191e8a36f132f81d1b81cec37496d9fe SHA512: dd04ac70358f4ed321460973dca6c9699350b88844232fcfffcafe8694d2d8e0b684764e125b7cc018a2e675543b7d0831ec53dc2ec89a86c14e44013b613dd0 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. Package: okapi Architecture: all Version: 4.10.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 74587 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.10.0-1_all.deb Size: 66876588 MD5sum: 1086bcc913870043ed51557d1b0996d1 SHA1: 880eaa9603536361da0a7fceedde2628fefb92d5 SHA256: c0fd5f0d5ee9d663a5cd4f62b9906afbe41b76d488bdcce9386c70d61f0aff5d SHA512: a080cf593fab8dfb4db6b394ff8d46de699ac49cf9a3199ec75e83defb0f324c7edcaa85522282c6ac5fe557e4c4c515315a90b97db84a4a21ed2f060b8ba438 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. Package: okapi Architecture: all Version: 4.4.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68047 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.4.1-1_all.deb Size: 60610768 MD5sum: 048a3cea8a7965edb6f86321a47465bc SHA1: 1a92a349cf3c9f82c16b07d33d507e055fa02f11 SHA256: 81f34c08a0dd3295659e47eb7d6e1fe7d0de96a6cb1d4e374731c0e221cc29e5 SHA512: b90fb94a8f74a51bc942152e536509d6fe771097f59ba739e75071dced9e20abb33ca8cad39078303134c4e105d40228e0a444d6942119d75ad9913951f56760 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. Package: okapi Architecture: all Version: 4.1.3-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62064 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.1.3-1_all.deb Size: 48934208 MD5sum: a8a9a13aa91f430e5a36c5af859a3742 SHA1: b90705f06047fba816c486d180a2231ac984fd7b SHA256: d0a9fbe171b38084554d3e3c0017c7536a4e3ba9aefb64856e81936a028aa1d2 SHA512: 61bbb25e0fd53b7758454a0d62bdc6befdfa43abbc3055cc1a06fd378a0566db9acba26f93c005eb1e3f8e8f8abcc0648841b6a2ed9c201371debb7dd301bb8f 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. Package: okapi Architecture: all Version: 4.7.5-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 69804 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.7.5-1_all.deb Size: 62323524 MD5sum: af506f31431ccd77a12d65f0b7eff6ea SHA1: 5bd26fc3021d49ada20b42aca045c2254eac3139 SHA256: b4d46df1f853cd8ba63632372ded514f8744972f0bd05dc275ac441777e31cbf SHA512: 88e964840562ed8090dd7a1ae9dac9942cb9b9d24a4df2fd0d01c8cd3ec6f87e9ae5d06ace7ed5586f669d3daf1f7769ac365b2c77df27376b2c09bcd58fb0a1 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. Package: okapi Architecture: all Version: 4.13.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62589 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.13.1-1_all.deb Size: 54038580 MD5sum: c71f60d430f0564a33a12369a5548ce0 SHA1: 2620bebd345046bed1df804599d6a5fd91da0d9a SHA256: 462b50cceea05b6d14f2e0f8b177f68eba63b665381e5f4167468e525c03fda0 SHA512: 157df254ed331f5b3d26bdc9d0ca8e3f84a2047ac4730057252f5f02d243869aec9907499b27030dec58559399a8b0087eca5a826832cc40cbb8e36eb278205d 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. Package: okapi Architecture: all Version: 4.3.3-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 67767 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.3.3-1_all.deb Size: 60357556 MD5sum: fc0c91a7b46d77a245275c318b0eef23 SHA1: cecc17c9c824261b40b6885539020d28b88f7516 SHA256: ed2d421a72e3e153f22ce4dc3a93a81f0bc699124c0643a0ead249a06113fb3c SHA512: 95f13a6d89c6b753ed88fe77e77f4827655981d380db42bc7e1a1e477c75eac54d18ed23a53e4fcd920bb785478e69c7a9aae183c083eb717db9f467116e7b63 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. Package: okapi Architecture: all Version: 4.7.4-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 69365 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.7.4-1_all.deb Size: 61875048 MD5sum: 5817b2b27b4dbceb333808f7d3f05149 SHA1: dd22852dcb04d46537623d051af3508420581c7e SHA256: 9d290f9da8d1516ac6f01527cf37a86315a82202c6a87906e39cab0064bda938 SHA512: c12769c6aed4a1cb84514b10d2156ed414382fb946247ce203610bac6faf35bcc8606013df52caf049539590de7639904eddccfa3cc58dd7bd84b55ef5f2965f 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. Package: okapi Architecture: all Version: 4.3.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 67767 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.3.2-1_all.deb Size: 60357952 MD5sum: 086a9fe03a3051d390a3970b95abcf2d SHA1: 4a20cb2f6eeec2b85a373eb14c57012b7b313632 SHA256: eb9b2208539d3cd389fd5384b5f815618dafe8a32431fa48d3630ae52b85c288 SHA512: 19e6ccf91c31decf372febadb2a4fc75ee092ed17c0b91366860c9a5d1bbba0ec7b5f49f0c3a848fc09cb3c0cd215f3b1d70b777ec569ece552eb1dbb9188f62 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. Package: okapi Architecture: all Version: 4.7.3-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 69372 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.7.3-1_all.deb Size: 61882628 MD5sum: 730f2ca99234bbcec76b5be52153d5ca SHA1: 2ccc99b86ca464d198dd2f5d9ab16f9f95d86366 SHA256: 738ced238b20198ca625210dc1f2437449543142d533b3a9a962e8736329cf51 SHA512: 81a0a6d8b9778e812946334d88573aa028345a099f974ab4d70f835163d94e3422f066127fb660397f6362c8a7159ab3abc053ca94ee3d3433f50576b54a38ca 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. Package: okapi Architecture: all Version: 4.14.13-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 64053 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.13-1_all.deb Size: 58644204 MD5sum: 8e0d7a20a1be4bd1d38f2e39cd7bc1d0 SHA1: 46f3daf370794c06485820a1a0c6244528199c54 SHA256: 61d8bdb3567a5b044d005712497f8eb80b5b1a0f0005f06a9b25808c55bde45c SHA512: 43289d22a878cd1d6c2e754e67a697d48c4d7cbb042d79e22b0710f417ac0ba9a9f98ef5bcffacf0b5b51074c85a5f78849ab0842e6bfa10f3ff7b761aae5bf1 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. Package: okapi Architecture: all Version: 4.1.4-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62064 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.1.4-1_all.deb Size: 48933272 MD5sum: 4410c554669c67f358badc1176ea7264 SHA1: 2d6da4503f6999ae16093a797597c8e5c4d6a272 SHA256: ba38c22e21ec80b84cbb26febb60b07aa6d02e9476558b40262385f6e54ffda9 SHA512: 43c2b64b5044be5b5cf7f342773a7f1efe556fb9d971e6ce1e459a47b572bc4346e54f008048ba4bfacc0b42615d9aa63f4c6045f6887a7ff1cf5b04eeb9311a 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. Package: okapi Architecture: all Version: 4.6.3-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68125 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.6.3-1_all.deb Size: 60680708 MD5sum: 0ebda9954691ab25d31be8a82012990d SHA1: 7e1062b697040284f9f8b922c645229826ff1132 SHA256: 864eeb314fd7c5ab64c03eb595185b8167d0748ec6504e45e95bc8152a9c3437 SHA512: 2c85575a322a767c36a808d9b10ec3731330f1fad8dd35c92d8dbf7d7120e05b42b1d72e45b4f5bea579947cf1be45ffd802d75899670cbca663c5c9c13beeaf 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. Package: okapi Architecture: all Version: 4.9.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 71732 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.9.1-1_all.deb Size: 64100608 MD5sum: e85cc1ff89251388d7379f182b374c8d SHA1: c1760889826b15fa0bb29030afdc51dd17257b7f SHA256: 01c5dcd9bc70c14fafa697f38259c136201de59087890ecc38d837f2fad57aea SHA512: 744e458fcbcb65d7a9dcdf6911f16077ef1cfc5d81fb1ba6264022e97be6c66af2a72f0b1dca366202c6884c580dedc129e98e12a0f9f4e0f51a114d6392f989 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. Package: okapi Architecture: all Version: 4.11.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 70501 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.11.1-1_all.deb Size: 60842620 MD5sum: 9e45cc0e130c9df0453c65a42aead378 SHA1: 8416230a0898addddf0d50a71c5c54ea36196bc0 SHA256: 9451ad5f95d024d5b2665ce2c271893102b9a92e33fd04130052cf5d88c16a79 SHA512: 08ac858c959ac74a23607d9a6afb9c56ff7945cf1aa555603308867aaae325d6a766ddf62c456f00c13b485d51d8d24e52d7ceef2c2f8e66b3e0ef5960dd2a2a 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. Package: okapi Architecture: all Version: 4.13.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62128 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.13.0-1_all.deb Size: 53388332 MD5sum: b22f440138dfe19605b35d6ab23a4ac3 SHA1: c567eb237cb603f0afebf5a2a3ea4d6a69d1506e SHA256: 35ac0be2a1dd6a0468bcde23d316e393b00582e6c900252203b109d0d58d1c1b SHA512: f9e1fe43185c945d06c82b11c09ed95da1e7ef59a00f27a1216d8f362a6b304b1e2232a9efb8a58749fc05633a4eac6acfa9ccec1bf745cc83838b94d7cbb0e4 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. Package: okapi Architecture: all Version: 4.12.4-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62130 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.12.4-1_all.deb Size: 53184008 MD5sum: b3b971c65c69fc69d244bb34e1345d7c SHA1: 99435119422eb5edbb704cd02d7d3eadf994cef0 SHA256: 96a2a5684777c6c73dc1f52babfb684b2a365ebaea12b43f26014e711d501bb6 SHA512: a51000aadd023e3046053d71b7d8c7bf07269f2d8f65806efa09bce47b97def8ec0f26e19cb995987cfd1b5b23a0bffbb33887749e20f8a5a6b1b8c6e0fe7658 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. Package: okapi Architecture: all Version: 4.14.11-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 64052 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.11-1_all.deb Size: 58642088 MD5sum: caa897befab27b8fe473b8db0ab763ed SHA1: 7bbc59fa93cebd498d64b7cc323a2a80a9be39f9 SHA256: d51ae37e50bf11884719fabd0809d0f491b392807da0e9406f96c384bafccea2 SHA512: f987dda7fea48d3fad21946476a952f97b303f65d341d129962e7c3c6c09997a185de4a2b30db21254c31f6be61ab75ba025811416d3b51920d6dbe18325b06d 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. Package: okapi Architecture: all Version: 4.7.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 69371 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.7.2-1_all.deb Size: 61882896 MD5sum: 1137f2c061623b3972d96273981b5c61 SHA1: 84f4cfd479e841eb4fb478fc4b99843272ad0eb7 SHA256: 9b76c7b123f1de1609418c05e45a2c6e0b32c59926e8acd06d6757915ef11d1e SHA512: 202a8ec01ecaf74092e4d446e2914870d858c00aa66e4fa2bb6debd241ae0ea85e51056d0df03da5a9dc4f7cd93f5640bf8406660e1289a280816d4b0216235b 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. Package: okapi Architecture: all Version: 4.6.4-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 69372 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.6.4-1_all.deb Size: 61882940 MD5sum: 8d4768f7bcda196671e8bfebf5280036 SHA1: 198c202daedf557444fee40ede35fefa900f071e SHA256: ffd19c8b3004c44c60855126d39389d1ae4f0c867e3b085e8e1565cfad22cdc0 SHA512: 4bf01ebb16efdad855d65f06c4864d9472a0e83128c3c1011a229f2fb7974c2dbd353cea9712af5d4d0a29af7bd052295c2443e126b928ac08118e32f7c0e767 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. Package: okapi Architecture: all Version: 4.14.6-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63277 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.6-1_all.deb Size: 57970076 MD5sum: bc7730495c7677f65eff9068e51a0aae SHA1: 3ef970e59f057e9f562ec2a8052b0f2021d5ba4a SHA256: a089fad8af6c77d0c748a97d4ffe6cf4c3bd55da4002c1811014bbc6a6656e44 SHA512: a5eccdbce7295eaf7768d7fbd63b922c362529da3cff0abf358e3c2f8901927ef6351453962b391e857a9631dd2631dff86cd057ea6bc3bff2716e54765f3d09 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. Package: okapi Architecture: all Version: 4.5.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68116 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.5.1-1_all.deb Size: 60675016 MD5sum: 326196b22d116cb751a171dd8fd271c8 SHA1: 9616c6417c272cdada004e261c6f690de88296ac SHA256: f265a36e30fe7ebbe5f1a503e0b4f335c11dba10adffbec5396a82b1d4678646 SHA512: b994491a4bbc16e829cb9a8910dfc3c79fc78dab75be8a0fdd2d807feae774b85b74d296adb0479cee8d1463ce883e6da6a66d334f7e68f353caae300c04557f 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. Package: okapi Architecture: all Version: 4.11.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 70335 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.11.0-1_all.deb Size: 60778520 MD5sum: 6d7bb4a4925225028745e12049c73bfa SHA1: 987dddfc71148e4ff6d0f42ce52a9f100dd21bfc SHA256: 170eff769bb1bdfca707ba8dcb4d6e205346a4897379c6a67d8341afadd54bb1 SHA512: 3d1489a137ddbb2fdff3f3c9324d08ba2d0cac4ac671ba7048481f07c2e3e65857524d3ec139d2fa11372fbaf0cacde06ffed984d905b6587754ca17643f3c4b 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. Package: okapi Architecture: all Version: 4.5.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68116 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.5.2-1_all.deb Size: 60674760 MD5sum: 1015ef64d07b9436789cd10dddb939ab SHA1: e7e4ee61117cb278a140e773cc4ec76335989348 SHA256: a59836db08ca27e137a7085fd5a2e12425c07f57698057f96a3c34777778f4a0 SHA512: 5202b9ca0981bf0ef13d79dd1c738ba7afb866b9925022d35458be60af1eb98aaa1d113e41110973e95a9e588a90e44cf566a3be5487ef1b9b5b19718e054afa 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. Package: okapi Architecture: all Version: 4.1.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 61763 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.1.1-1_all.deb Size: 48709200 MD5sum: 729f43af4a42ecffbf89b1409d7b505f SHA1: 79cf08990cf8ca7eb11f46a175f07045b04089b4 SHA256: 665f05936aaa9d11902fefbdc6f779baad8b9857b0545c89a8fb9c64c445ed0a SHA512: 0d10b1cf75c6b9e7bfc8c5e940e0719874a6c679348600ab3c4ff2335cac532883d0cd7da82a26ec12266b26da0d717d35abe8021ce78fc0e3002ff4946c1420 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. Package: okapi Architecture: all Version: 4.14.5-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63277 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.5-1_all.deb Size: 57970916 MD5sum: 039ae61b2b5696e6c558d700b9ddb463 SHA1: 869fb6d451b070698f83d8fdf39481b8769f29ae SHA256: 002bb62125af344a3077cdd1f7280574e5c88ff08859d4de9c56c33950cce0ca SHA512: e8a04ca93d530756bbeac12ff7c389dd25ae168309fe3d57accd94edb96463b649579198547a4e9ae15d50de7c07956ae1ff729cf469729b4396ad0453392e8d 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. Package: okapi Architecture: all Version: 4.9.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 71299 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.9.0-1_all.deb Size: 63658736 MD5sum: 8c29915f9a4300cca2335ea6063be596 SHA1: 1382ccc25476653a7218b3c1f8e4aa822ea66cea SHA256: a0975522bbad035543e560d22dbc909f25462687add118b97ae4cff8d666985c SHA512: b071a008766d59bbc371d4cd5f1e4625a06676c67685596cb0fca5a4098cf9bf30efb304f2e3d9599f98d405badb84c7a49b8369c9112e51e5e7bcf560543d72 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. Package: okapi Architecture: all Version: 4.6.5-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 69372 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.6.5-1_all.deb Size: 61880856 MD5sum: cf12e083feed0ecc74359aa008f4cd3f SHA1: c5da47104f0425672e6dc9d356348102d8d54081 SHA256: 777b2abf54ed2ea9f6e917941f1b3f9369fc774df11536de14dad2f7265a928b SHA512: 424684cdcbb41a7a9719f247d1b6333a935c8990c20c1b2b6d3d5aac2738aecba1f1ba0092e3cdb41a804b84573393caa02d21842239d90e79c905964a85bb85 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. Package: okapi Architecture: all Version: 4.4.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68048 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.4.0-1_all.deb Size: 60607316 MD5sum: 4c35fac8db8089ccc2d0feb715e7975a SHA1: 062fc8b77787da4c6d75d123b97d9f1483311c49 SHA256: 82b3f6237305f18af3f26a648f499a9483dde8099d44ed8a28ad6c01f515e1bd SHA512: f51af20f2e4f5e28746eaf3414ae8e2095064779b7f32b916e31c457db31aebd142aa38badccb9849a5fe1a7d036846576369d7601c0e8981f567da718a93f99 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. Package: okapi Architecture: all Version: 4.8.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 70518 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.8.0-1_all.deb Size: 62943056 MD5sum: 51a563ae3d763bdda95916110f17cea7 SHA1: ed272a7550d981ea67ee64d5df7c4d80faccecde SHA256: 32fefae1503265526f6f61a0fdb47c53a11116d1b2cb6c7d8733b4af7e046b45 SHA512: ad55e98599900e8e063d65a5ffd3e80745d140a63316b61ce7c24f61fe1d18a9265cb2257e8e6dce964dc5ff6447aff801f0ab3ce57c1326e429f590905ff90e 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. Package: okapi Architecture: all Version: 4.6.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68125 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.6.1-1_all.deb Size: 60681840 MD5sum: 29d8cdc3d77de21b2e63a1f1204b5560 SHA1: 61afc3e92827787c923ce9eb043260d72d57407e SHA256: 935ba3c3de74be4639d98c99892e09cb91f4417507e9a465d799481358ad0257 SHA512: 05a3b95509c6ad1f94e8a8ddff337afafb11f48a722304306fe1e75a6db96436d83ace12fd7dcc8cb4a484c864ef83b6a1c42efd5a3d27043d91c0b42da6d15d 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. Package: okapi Architecture: all Version: 5.0.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 64350 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_5.0.1-1_all.deb Size: 58890384 MD5sum: be4d8e993e6d2a79c9bfbfbc2a496627 SHA1: b284d0bc356f49bb5f84c93d5a76b797fd54c7f1 SHA256: 16252924c88a8ca1aafd9379905058666c63bc89d0b8497dd646eea6a7697a08 SHA512: 23d06e4d0c0fa21e9b395c409fe99b818c615982f584fd0d6ad7ba16991a628f9f11e9c2549525d119caf35ed62753b9e63933d676b35f200a002279ca5b6805 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. Package: okapi Architecture: all Version: 4.14.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62778 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.0-1_all.deb Size: 54395140 MD5sum: 8179968716c0a59d11e480cb598028f5 SHA1: d2d9255e7fd923a35149e15fb7b4441c9dd8eb92 SHA256: c87780a2fefb5e4bdf4c5815d6aa51a4cba67b466b18c5af74993036f5fff16a SHA512: a762213c9550cb76397f739fce157ebdea8dea3a5bbb4afa2ad1470d9ddd0176e28f584f846b3b4905a2da9ecb7bc417e483fd06a5a621cc62acc078a1cc9f88 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. Package: okapi Architecture: all Version: 4.3.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 67764 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.3.0-1_all.deb Size: 60354156 MD5sum: 3a9ec8c6114fbea835b46cdf9d032684 SHA1: 1196c32140ebbf6fe37de77f78e2d58e5f1b852e SHA256: ee5d5af104d6e9353fd5a529158d5b8df1e8e5cf31c6d274f034a42b619c8900 SHA512: bf02e1ffa19637020d36cc4cdddfd092e2666ef470d0e0439c639d8b6a61a5428522d511e77779ae38f1f63158c788859a5f0f57d9fc2b4920ed7b1b64f23fdd 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. Package: okapi Architecture: all Version: 4.14.3-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63416 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.3-1_all.deb Size: 58151236 MD5sum: b44f2ce54e91054240b54fe8f7f889df SHA1: 7c713f5222d5e1e6da350fe40e48ff805b52bb5a SHA256: add0ae12abde6f2641ce95da1d94a4c98448d00f51bc0cfeb2b324346bfd58db SHA512: 7a98338bc8fbcc8601f3d36f4d905e3db993ac4a93f181baeba3a29b4c8b745fd73d9350843e94ae00f9399867a7c08ba005ffe996f164114b7067fa13dcc72e 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. Package: okapi Architecture: all Version: 4.8.3-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 71005 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.8.3-1_all.deb Size: 63394292 MD5sum: bbe2e2c0bfdacda6748f99a89a49b5cd SHA1: d3bb43e5d95c930af7db2378b3879f069df9ef34 SHA256: b5cd2b90698720d3e26f0463b90402a57d22c56985e18e85f3fab1446c9602f7 SHA512: 9ceee86225eb4c42aba42e5f1710a08ac28f4efd06e42dad9976be3f4eb33c054e6d3a2ad94b57288fd39ee6e45d291c65231a30cdeddf74184fa85329606d24 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. Package: okapi Architecture: all Version: 4.1.6-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62379 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.1.6-1_all.deb Size: 49301452 MD5sum: 7e9455cd1efdaec7f1af0ff9b16afb07 SHA1: e6d43e3ae941938ca2bc0152882897b0868bcb9c SHA256: 85118542881b09eb40be97b03222970eb3572db8a682a7929791d6c55706779c SHA512: f4988e8e870052158fde2d1447512a08b858e6a9f45a2d7c50ae1aeac6eb68b9014fc8f907e3f6946b826d60163161bcada0d3ac653c4e84dc1cde66f5e64fe5 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. Package: okapi Architecture: all Version: 4.14.7-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63277 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.7-1_all.deb Size: 57973128 MD5sum: ef0e219840e4e5abefb6fae7a516be06 SHA1: a572be70ac8f16f001153a609f63f56d7c69500b SHA256: 701420b25e1c35b2f071755de6b9c8501833c423fc283195217eded6b36055a3 SHA512: e79dec6002cd8ad069f93ea60fc9be13d4089566b51e40d094639240c2013ad41831a401e28cdd0eba1beb2654d0a2a40745f8754598b31be7a27d7adb229748 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. Package: okapi Architecture: all Version: 4.8.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 71012 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.8.2-1_all.deb Size: 63399956 MD5sum: f6d49bc5a6fde3e4a4f1fe79a2cf6efb SHA1: 7493fba80d415465fd366e218e50b46ac1256280 SHA256: cf2a533ecc8e799a6141a45e5b85cf1b4b8bfb135fe758ce37c41132bb9eb608 SHA512: ab1785334bc66bc1926935843685a1cfe463401b95eb8b9eb571768f8030fff47d0c0e2cea5794a6eee11b09d19a233ad161d4f7630b35f2ad5bed0791d9427f 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. Package: okapi Architecture: all Version: 4.1.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 61767 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.1.2-1_all.deb Size: 48714456 MD5sum: f0121452d8f7a4ba9adf241e9676e788 SHA1: 1244d615300cebaa957a520d63b08ca7436cc631 SHA256: 3825e1b5749d5eabe7f1437d943f449d894354a0a11874e12c7eb82f1f9c88f7 SHA512: 8df10dc2b05e9180e8b701578e46da77c5bc74520287447e5fd694421c6d74bd8efdbac1f3172cc423bc9df836dd50c44af3e196da430fc397d45a3ca5a926d5 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. Package: okapi Architecture: all Version: 4.14.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63270 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.1-1_all.deb Size: 55329708 MD5sum: 2610764f575a5720bd4307bfa4991f19 SHA1: 329be58489dba9e764918ebfa6dad685b0444d22 SHA256: fc9c806dd459fce8117f6c91c044f3beaa9d8f283c858dffd6f09305101b171d SHA512: e139b42ddbdae33b105b5a5a313805a63163c2550e87fbda430f1e79173d322916637476d19f3824961a1fd5178ccc69909dbd3487ba1af7dd877b1a2d542ff4 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. Package: okapi Architecture: all Version: 4.8.4-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 71444 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.8.4-1_all.deb Size: 63845464 MD5sum: c15cd153c19ac597c27d2e73b3ab5fdd SHA1: 3fbf2d967487ac3138287bd1acb71aa00268793c SHA256: 187d6d6d17da03cfdbe8676f7ddb6875620890d08fa2cda6d230e10e4814b8f5 SHA512: 9e01cc9053b7fe45bd0abc4dfe391a39096bbb55d4823cc0b5474c77b5c0e541435d5c27e09aa3aab98fa4117e79b7c27459b6b78d5e7c89fc1c86b111230cf9 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. Package: okapi Architecture: all Version: 4.5.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68116 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.5.0-1_all.deb Size: 60678064 MD5sum: d5c180edeb48b0c826323830888f50b8 SHA1: 393a8ce5ba3dcd78c1e61d9c1ff43ed1f0c5c85a SHA256: 117ce7bbc263eb26a8a412a013136c6a8e6c99083640bd87af7a39e13fd1a598 SHA512: 485032f3c0047483442f5741f313d12e7240f218610762b1ec747368d0510e26190217c6674e7f178ef1e87edd559c7ce73a5f75685a54eb73689af37b54a14e 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. Package: okapi Architecture: all Version: 4.12.3-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62130 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.12.3-1_all.deb Size: 53181388 MD5sum: 925f1361edcabbf4f486be4535400ce6 SHA1: c57b98c9298d5c1257597a9cc285f4c34ee03be6 SHA256: 3c0d1cb403f2756f5504d4f807f89acd4aa152d1404f2f4bef4b01d1a2ea9249 SHA512: 88f318e735704d1ba1eeeea25f1dc869fa7d51b20038508395ef037df68991fb1d23322e489c7b45adfdfc6ab36121574d59e41ef06ab8c25706449e765e344d 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. Package: okapi Architecture: all Version: 4.1.5-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62379 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.1.5-1_all.deb Size: 49304656 MD5sum: 79851fe75e9554cc868821be8219f57a SHA1: f168f50b0cfea6a13fa2d7d241f29568b36bf7ca SHA256: 751b665f0da9e445d04f3c614ccfa81f8dd918683045549474d32ce8740f01dd SHA512: 67134effa3d720d7d57041bf41b5616173fa6ed1ebc5ee40a5a92ba7e27d2cb6bd768519a6f9ea63c23569f343c5f5c43855dae84f6c6ca0a7655f40cb46cd70 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. Package: okapi Architecture: all Version: 4.14.10-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 64052 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.10-1_all.deb Size: 58644432 MD5sum: 9166c34eb6086a4a964c8e013bf4f95a SHA1: 6606f0491758c43c5c45b543c487b5c5436d1276 SHA256: 0224c4971f1775d978ed9202662fae1d19cefc141444c3c0ee3f83134652f127 SHA512: ad9fd1fc707b26b171543ed76df8d9f25c55334a3b1066fd3c9670c957e7d7a928d270ff5d0a67c2e82f024bb5f6b6a6699f8e9a8755c83bf11a3c122d33fbda 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. Package: okapi Architecture: all Version: 4.14.4-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62666 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.4-1_all.deb Size: 57436264 MD5sum: 89f2005e2918a085fb1ed45aabd48582 SHA1: 86925dd957b552741fe77c0004c6bb7430b510b7 SHA256: 0164f675b349efc70b7218ef70390917bf09cd2a94a9d2a75f72bf4fe519ba6c SHA512: 7af7f75a5a2003bf3a0ae107711be403106e681c7820361d0fc4901afe014f413bd1dc3e92c3fac4aa79ca44faf412cfe1e54b1bc2e59e09b309de4d2918f8a8 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. Package: okapi Architecture: all Version: 4.13.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62595 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.13.2-1_all.deb Size: 54051280 MD5sum: e71ae9fa95ff941d3ad3ea648de15432 SHA1: 43939ad309bc52fdc3330257c9abf812b7c19d28 SHA256: 0b9af3158d4582ceed49a37a30551642db2e21d4d2785bfa4bc71ba1704a3fdd SHA512: 864f26e18035a771da15b6c69ddf623df032d683b44a35d603820f5f20a1b488ac9d617831bacfabc0b941297eb894569879e1a8f13aeb4aeacc79ad4d75cf5a 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. Package: okapi Architecture: all Version: 4.12.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62075 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.12.2-1_all.deb Size: 53084808 MD5sum: c8527e1db9278deb27ecc9759c97dbf6 SHA1: e620aa536e45d2231f03591674d24f18a21c8f07 SHA256: f75c561455eaf92161adfeb34e8cd41ddc713f162a969e00f30a26a94b76dd54 SHA512: 96791b3c52b4d9ef625de455b1ee5be1c409636598a8c8ccaeefba60720a2224025398a3cf4ebcfd9b64ee082847a0266be73af8aac9a803753c2c3b5581c1d4 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. Package: okapi Architecture: all Version: 4.6.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68124 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.6.0-1_all.deb Size: 60679700 MD5sum: 058726aa58fab0de1f4091bebfdf1559 SHA1: 2e940a78beb4a75ab9cc9c9da0f3dfeff53ab043 SHA256: da7c9fc70992668c7d8d759070b436a740f3daa8b0dccac0fb74e5581c5e5fee SHA512: 2b60e3c741eb19e11d870a0d27033e3abdf4278a5bbe78677aacd0ed4ff28f4984a2c49c5a6c2227b2a59b0511c1de16014123e9b7028aaa60ba1e4a308321f3 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. Package: okapi Architecture: all Version: 4.6.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 68125 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.6.2-1_all.deb Size: 60681580 MD5sum: c1087e5844ed8b058bde0481911b021f SHA1: 5f731f0798b0e792f5de5a260d5108ef5f2bc5dc SHA256: ec460de82a5ab441665b2c576e7ffbd34460aba7f7fc37acd741caae087c2bc3 SHA512: b1001057106d988646687c57501bf34c63af85b9e9dec56e55ed8dfa213606461d4cceedd34cfcdc4dd64f834697556abcb2f22b9ca825e65af297de8143e750 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. Package: okapi Architecture: all Version: 4.2.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63262 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.2.1-1_all.deb Size: 50050476 MD5sum: 4e5e22c0ac6a0f41c9cbce8617ccc5bd SHA1: b3b73b7b63a70eb6dea9a0d0ffac66f2256c2652 SHA256: 5d9ed0c951ef4ebe4e5aa18b917a47f73afa22d8af38a530dac6afd2954c7d42 SHA512: bf88347c68fc6080c0c95ee393b5256eaf730fec07a8c097c5463563ca7ed4063123c245edd68f5a1c62205125b8b72e64ee8de0d51e9cbc265443fa3d3e62c1 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. Package: okapi Architecture: all Version: 4.8.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 70519 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.8.1-1_all.deb Size: 62943340 MD5sum: 58272e2e2ffda935d73ea467d2b308d9 SHA1: 1c83b52d3fdee39c1ef31774af870a1264c6c52b SHA256: fdf4d21ed5a6dcf31658e0d25a9f74900ff4bbccbc2a94eafece39486707cc6a SHA512: 48a4fb4f2b424b3d44e294b65e1e39173dd64f39dd623211d548aaad79acb832788c6b8fd972849e0e0b508bebf36b3e78ac364e3ecaf87c1d5738451a226beb 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. Package: okapi Architecture: all Version: 4.7.1-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 69371 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.7.1-1_all.deb Size: 61880032 MD5sum: 9daf6cc8efe60f368427a21ce625b884 SHA1: 482f5f394889e9c6b3bdbe76db624668fe6ebcf9 SHA256: 6cc0b98f42f1b54d7d5587abd834b723a8e26eaa8e87b654617e91bcc2c58352 SHA512: 232fae5cd259eeeb4a1fd7ade41088c10e2b839db89f2f4de019b8ad963cb168752bc88586b1aced726bef8bb2e5e69cb315daa924908d3f076b5b9c13629ad7 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. Package: okapi Architecture: all Version: 4.2.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63262 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.2.0-1_all.deb Size: 50048980 MD5sum: c7286b481f6861f8c6d2a413e3dec94b SHA1: 9ee5ca14b1a32526f0a35fde0d9fcc7e76652d67 SHA256: 56813ff93a119f3d3b279436196f58355fdcc293df34ee916e1ab0ac211fb407 SHA512: 8f9d0dce166193574d35cbf437bebeabdb76d0bd428395c11c433ac4bb2974ee888098c6fa90be44fa57ddc4cad113e37c4fc56cbd61ef5ec555ba32b450cb04 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. Package: okapi Architecture: all Version: 4.14.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63272 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.2-1_all.deb Size: 55333208 MD5sum: eab56705ae202bb0e48fa2cded3cb5d0 SHA1: af04c2e0911a0c3b4fe5f079125c73c9fc29806c SHA256: c71bbfce817264903a5134160cd0ebc4e91fe39c48acade94a4d0f92def11ddf SHA512: bee326f7fb2e9a9150de254d74128d27b434f32380081c72623edeefd57b958de20c01d62e89ad3f6dd515fa768680bf5b7a3f6a95db02ec84012f07d8fc4855 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. Package: okapi Architecture: all Version: 4.1.7-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 62379 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.1.7-1_all.deb Size: 49307000 MD5sum: 57258963ce43a1955ad7f21d13d68231 SHA1: 62e339097214e67dbcc1bbabfc0dce37ed9ecaa8 SHA256: c185b13bc9de2aabfb799af69a21172f25f41956116bd97c1812b7b3d6c85de7 SHA512: 81e7e0d13b5fce7e19db3dabb922e93465db2dd0526aa73e89b97be3b044b177cd3245fca49b7ceeea829c078d009f7622d51bc03bf52957e3bc6bf30993521c 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. Package: okapi Architecture: all Version: 4.14.12-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 64053 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.14.12-1_all.deb Size: 58649444 MD5sum: 865c6a6f22239a375b52d183c0e61062 SHA1: e3630eb7ed3e321414cd2820ec8e7235da3e41fd SHA256: 709db45cc0787480a31d6103a0eff9018b9129eba8463a25dd00b7dc021919f4 SHA512: 4038c449d826c4903c783dc4dffa95e052b8fa143055674ba7ea9679a0435215ab9d131d3879e8c7dc904612ce7d15e9992359bacadd63a3d5fdc045ffb152b7 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. Package: okapi Architecture: all Version: 4.2.2-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 63263 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_4.2.2-1_all.deb Size: 50050572 MD5sum: 3144e28ba02c2c849a90aecf6cadbf64 SHA1: d67fca3b4ef9e0426a5bc5dda42b783b6a6ef565 SHA256: 9191b3bf028ebd25d2ef25708fd072811778fb76a89f3b051c703b5566313a24 SHA512: 6fed99dc3f5463bae11f24ab27925b5a353c62d46c40739c2fe7b84408b9ed1201a86c4f9c9744452107ecf8670494cfa83ddcdeece83e0ebf675cd84309ea1a 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. Package: okapi Architecture: all Version: 5.0.0-1 Priority: extra Section: net Maintainer: Index Data Installed-Size: 64348 Depends: openjdk-11-jdk | openjdk-11-jre, jq, adduser, postgresql-client-common Filename: focal/okapi_5.0.0-1_all.deb Size: 58885496 MD5sum: 40c7ee02741fee52c7bcde6de45628b8 SHA1: 3c793d65a1fdd9b96586739d31eb5e6c1813ec2d SHA256: edef3657fbdfbeda35d5b977019efe492c49d83f05ae0a9750dca5a7680057ce SHA512: b07241cf339b42746d8b01ae56976b3c280d3b8f7af0623939eba3405b2dfa1afa5ba9cec72721f08af782ff9ca42e707ce140cbcf9f1c18a4db93954916e495 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.