Binding backend service endpoints to API functions in the API registry

Abstract

The present invention relates to binding backend service endpoints to API functions in an API registry. A method of providing application programming interface (API) functions for a registered service endpoint in a container environment can include receiving, at an API registry, an API definition that can include an endpoint of a first service encapsulated in a container deployed in a container environment and one or more API functions. The method can also include creating, by the API registry, a binding between the one or more API functions and the endpoint of the service; receiving, by the API registry, a request from a second service to use the first service; and providing, by the API registry, the one or more API functions to the second service.

Description

[0001] This application is a divisional application of the PCT application filed on September 28, 2018, with national application number 201880069226.3 and entitled "Binding a backend service endpoint to an API function in an API registry", which has entered the Chinese national phase.

[0002] Cross-reference to related applications

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 566,351, filed September 30, 2017, which is incorporated herein by reference. This application also relates to the following jointly assigned applications filed on the same day as this application, each of which is also incorporated herein by reference:

[0004] • U.S. Patent Application No. __ / ___, filed on September __, 2018, entitled “API REGISTRY INA CONTAINER PLATFORM PROVIDING PROPERTY-BASED API FUNCTIONALITY” (Attorney’s Case No. 088325-1090746);

[0005] • U.S. Patent Application No. __ / ___, ___, filed on September __, 2018, entitled “DYNAMIC NODEREBALANCING BETWEEN CONTAINER PLATFORMS” (Attorney’s Case No. 088325-1090747);

[0006] • U.S. Patent Application No. __ / ___, filed on September __, 2018, entitled “OPTIMIZINGREDEPLOYMENT OF FUNCTIONS AND SERVICES ACROSS MULTIPLE CONTAINER PLATFORMS AND INSTALLATIONS” (Attorney’s Case No. 088325-1090748);

[0007] • U.S. Patent Application No. __ / ___, ___, filed on September __, 2018, entitled “REAL-TIME DEBUGGING INSTANCES IN ADEPLOYED CONTAINER PLATFORM” (Attorney’s Case No. 088325-1090753). Background Technology

[0008] In general, any form of container represents a standardized method of packaging and interacting with information. Containers can be isolated from each other and used in parallel without the risk of cross-contamination. In the modern software world, the term "container" has a specific meaning. Software containers, such as... A container is a software construct that logically encapsulates and defines pieces of software. The most common types of software to be encapsulated in containers are applications, services, or microservices. Modern containers also include all the software support required for application / service operation, such as operating systems, libraries, storage volumes, configuration files, application binaries, and other parts of the technology stack found in typical computing environments. This container environment can then be used to create multiple containers, each running its own service in any environment. Containers can be deployed in production data centers, on-premises data centers, cloud computing platforms, etc., without any modifications. Spin-up a container in the cloud is the same as spinning it up on a local workstation.

[0009] Modern service-oriented architectures and cloud computing platforms break down large tasks into many smaller, specific tasks. Containers can be instantiated to focus on these specific tasks, and multiple containers can then work together to implement complex applications. This can be called a microservices architecture, and each container can use different versions of programming languages ​​and libraries that can be upgraded independently. The isolated nature of processing within containers allows them to be upgraded or replaced with minimal effort or risk compared to changes that would be made to a larger, more holistic architecture. While virtual machines can be used to run container platforms, container platforms are far more efficient than traditional virtual machines in running this microservices architecture. Summary of the Invention

[0010] In some embodiments, a method for providing application programming interface (API) functions to a registered service endpoint in a container environment may include receiving an API definition at an API registrar, the API definition including an endpoint of a first service encapsulated in a container deployed in the container environment and one or more API functions. The method may further include the API registrar creating a binding between one or more API functions and the endpoint of the service; the API registrar receiving a request from a second service to use the first service; and the API registrar providing one or more API functions to the second service.

[0011] In some embodiments, a non-transient computer-readable medium may include instructions that, when executed by one or more processors, cause one or more processors to perform operations, including receiving an API definition at an API registrar. The API definition may include an endpoint of a first service encapsulated in a container deployed in a container environment, and one or more API functions. The operations may also include the API registrar creating bindings between one or more API functions and the endpoint of the service; the API registrar receiving a request from a second service to use the first service; and the API registrar providing one or more API functions to the second service.

[0012] In some embodiments, a system may include one or more processors and one or more memory devices including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, including receiving an API definition at an API registry, the API definition including an endpoint of a first service encapsulated in a container deployed in a container environment and one or more API functions. The operations may also include the API registry creating bindings between one or more API functions and the endpoint of the service; the API registry receiving a request from a second service to use the first service; and the API registry providing one or more API functions to the second service.

[0013] In any embodiment, any one or all of the following features may be included in any combination and are not limited thereto. The method / operation may further include generating a client library for a second service, the client library comprising one or more API functions. The client library may include object classes having member functions that implement the API functions. The client library may include direct calls to an endpoint of the first service. The client library may include code that updates the endpoint of the first service at runtime when one or more API functions are called by the second service. The client library may reformat data received as one or more parameters of one or more API functions into an HTTP call to the endpoint of the first service. The client library may request additional information from a third service to add to the HTTP call to the endpoint of the first service. The client library may include code that retrys unsuccessful calls to the first service. The client library may include code that extracts result values ​​from the result set of the first service and packages those result values ​​into the return values ​​of one or more API functions. The endpoint of the first service may include an IP address and a port number. The container environment may include multiple services encapsulated in a container. The API registry may be deployed as a service encapsulated in a container within the container environment. The API registry can be used for services under development in an integrated development environment (IDE) as well as services already deployed in a container environment. The method / operation may also include having the API registrar identify any available endpoints of containerized services that have been deployed to the container environment. The method / operation may also include displaying a list of API functions for all services registered with the API registrar in the user interface. A request to use the first service from a second service can be received by receiving a selection of one or more API functions displayed in the user interface. The user interface may include a command-line interface. The user interface may include a graphical user interface. Attached Figure Description

[0014] A further understanding of the nature and advantages of the invention can be achieved by referring to the remainder of this specification and the accompanying drawings, in which similar reference numerals are used throughout the drawings to refer to similar parts. In some cases, sub-labels are associated with reference numerals to indicate one of a plurality of similar parts. When reference is made to reference numerals without specifying existing sub-labels, it is intended to refer to all such plurality of similar parts.

[0015] Figure 1 The illustrations depict the software architecture and logical layout of a development and runtime environment for services in a container platform, according to some embodiments.

[0016] Figure 2 The illustration shows a dedicated computer hardware system specifically designed to run the embodiments described herein.

[0017] Figure 3The illustration shows data organization that can be specific to the container platform used by some embodiments described herein.

[0018] Figure 4 The illustration shows an API registrar that, according to some embodiments, can be deployed to IDEs and production / runtime environments.

[0019] Figure 5 The illustration shows the deployment of an API registrar for use with a container platform at runtime, according to some embodiments.

[0020] Figure 6A The illustration shows a flowchart of a method for deploying an API registrar according to some embodiments.

[0021] Figure 6B The illustration shows, according to some embodiments, when using Figure 6A The flowchart in the document describes the software architecture of the container platform when deploying the API registry.

[0022] Figure 7A The illustration shows a flowchart of a method for registering a service with an API registrar according to some embodiments.

[0023] Figure 7B The illustration shows a hardware / software diagram of the steps for registering an API with an API registrar, according to some embodiments.

[0024] Figure 8 Examples of graphical and command-line interfaces for browsing and selecting APIs registered with an API registrar, according to some embodiments, are illustrated.

[0025] Figure 9 The diagram illustrates a flowchart of a method for using a service registered with an API registrar and its corresponding functionality, according to some embodiments.

[0026] Figure 10 The diagram illustrates how the API registrar can receive selections through the graphical interface of the CreateUser() function.

[0027] Figure 11 The illustration shows an example of a client library automatically generated for a service by an API registrar, according to some embodiments.

[0028] Figure 12 The illustration shows an example of a client library that dynamically binds server endpoints to API functions according to some embodiments.

[0029] Figure 13 The illustration shows an embodiment of a client library, according to some embodiments, that can marshal additional data to complete an input dataset for service invocation.

[0030] Figure 14 The illustration shows a client library that can handle retries when invoking a service, according to some embodiments.

[0031] Figure 15 The illustration shows a simplified block diagram of a distributed system used to implement some of the embodiments described in the examples.

[0032] Figure 16 The diagram illustrates a simplified block diagram of the components of a system environment through which services provided by the components of the embodiment system can be offered as cloud services.

[0033] Figure 17 An exemplary computer system in which various embodiments can be implemented is illustrated. Detailed Implementation

[0034] This document describes an implementation of an Application Programming Interface (API) registrar, which is part of an Integrated Development Environment (IDE) that allows developers to register services during development and make those services available to other services during and after deployment. The API registrar can be deployed as part of an orchestrated container platform, thus operating as a containerized application on the platform. As services or microservices are developed and deployed into containers on the container platform, the API registrar can perform a discovery process within the container platform to locate available endpoints (e.g., IP addresses and port numbers) corresponding to available services. The API registrar can also accept uploads of API definition files, which can be used to transform raw service endpoints into API functions available through the API registrar. The API registrar can dynamically bind discovered endpoints to API functions, which can be kept up-to-date and available to other services in the container platform. This provides stable endpoints that other services can statically invoke, while the API registrar manages any changes to the bindings between API functions within the service endpoints. This also simplifies the process of using services on the container platform. Instead of writing code for HTTP calls, new services can access registered services simply by using the API interface.

[0035] In some embodiments, the IDE can provide developers with a navigation / browsing interface to locate services available in the container platform and registered with the API registrar. When the API registrar creates a call to an existing service for a new service under development, it can automatically generate a collection of client libraries that include all the necessary functionality to interact with the registered service. For example, some embodiments may generate object classes that include member functions corresponding to the API calls. During development, the new service can simply instantiate these objects and / or use their member functions to call the corresponding API. The code in the client library manages the direct connection between the calling service and the endpoints of the registered service and may include code for handling all the functionality necessary for such interaction. For example, the automatically generated client library may include: code for packaging and formatting parameters from the API call into an HTTP call to the service endpoint; code for tidying up data to complete the parameter set for the call; code for packaging information into compatible packets (JSON, XML, etc.); code for receiving and parsing result packets; code for handling retries and error conditions; and so on. From the perspective of the calling service, the code for handling all such functionality is automatically generated by the API registrar, thus abstracting and encapsulating the details of the service call into client library objects. All that's needed to invoke the service is to execute the member functions of the client library object created by the API registrar.

[0036] In some embodiments, the API registrar may also accept uploads of a set of features that define the runtime execution of a registered service. This set of features can be uploaded along with the API definition file during development. These features can define runtime characteristics such as end-to-end encryption, usage / logging requirements, user authentication, on-demand service instantiation, multiple service deployment instances for high availability, rate / usage limits, and other runtime characteristics. The API registrar can ensure these features are met by interacting with the container environment during development, deployment, and runtime. During development, automatically generated client libraries for invoking the service may include code required to execute these features, such as encryption code, usage logging code, and / or interaction with user authentication services. When a registered service is deployed, the API registrar can instruct the container platform to instantiate multiple instances of the service and / or other load balancing modules to ensure high reliability of the service during runtime. During runtime, when the service is invoked, the API registrar can cause the service to be instantiated on demand, limit the number of API calls that can be made to regulate usage, and execute other runtime functions.

[0037] Figure 1The illustration depicts the software architecture and logical layout of a development and runtime environment for services in a container platform, according to some embodiments. These environments may include an IDE 102, which can be used to develop services and microservices to be deployed on the container platform. An IDE is a software suite that integrates and provides all the essential tools that service developers can use to write and test new services. IDE 102 may include a source code editor 106 with a graphical user interface (GUI), code completion capabilities, and a navigation / browsing interface, allowing developers to write, navigate, integrate, and visualize the source code writing process. IDE 102 may also include a debugger 110, which includes a variable interface, an immediate variable interface, an expression evaluation interface, a memory content interface, breakpoint visualization and functionality, and other debugging features. IDE 102 may also include a compiler and / or interpreter 108 for compiling and running compiled machine code or interpreted bytecode. Compiler / interpreter 108 may include build tools that allow developers to use / generate another makefile that automates the build process. Some embodiments of IDE 102 may include codebase 112, which includes generic code functions, objects, interfaces and / or other structures that can be linked to services under development and reused across multiple developments.

[0038] Services can be developed and thoroughly tested within IDE 102 until they are ready for deployment. The services can then be deployed to production / deployment environment 104. Production / deployment environment 104 can include many different hardware and / or software architectures, including dedicated hardware, virtual machines, and containerized platforms. Prior to this disclosure, when service 114 was deployed to production / deployment environment 104, service 114 would no longer have runtime access to many of the tools used in IDE 102. Any functionality required for service 114 to run in production / deployment environment 104 needed to be packaged from codebase 112 and deployed along with service 114 to production / deployment environment 104. Furthermore, service 114 would typically be deployed as a copy of the source code from debugger 110 without any functionality from source code editor 106. Essentially, service 114 would be deployed to production / deployment environment 104 with all the functionality required for runtime operation, but information used only during development would be stripped away.

[0039] Figure 2The illustration depicts a dedicated computer hardware system specifically designed to run the embodiments described herein. For example, service 114 can be deployed in an Infrastructure as a Service (IaaS) cloud computing environment 202. This is a form of cloud computing that provides virtualized or shared computing resources over a network. The IaaS cloud computing environment 202 may also include, or be coupled to, other cloud computing environments arranged as Software as a Service (SaaS) and / or Platform as a Service (PaaS) architectures. In such an environment, a cloud provider can host infrastructure of hardware and / or software components that traditionally reside in on-premises data centers. This hardware may include servers, storage devices, networking hardware, disk arrays, software libraries, and virtualization utilities (such as hypervisor layers). The IaaS environment 202 may be provided by commercial sources (such as...) (or other publicly available cloud platforms). IaaS environments can also be deployed as private clouds using private infrastructure of hardware and software.

[0040] Regardless of the type of cloud environment, service 114 can be deployed on various types of hardware / software systems. For example, service 114 can be deployed on dedicated hardware 206. Dedicated hardware 206 can include hardware resources specifically assigned to service 114, such as servers, disks, operating systems, software packages, etc. For example, a specific server can be assigned to handle traffic flowing into and out of service 114.

[0041] In another example, service 114 can be deployed to hardware / software that operates as one or more virtual machines 208. A virtual machine is an emulation of a computer system that provides the functionality of dedicated computer hardware 206. However, instead of being dedicated to a specific function, physical hardware can be shared by multiple different virtual machines. Each virtual machine can provide all the functionality required for execution, including a complete operating system. This allows virtual machines with different operating systems to run on the same physical hardware and allows multiple services to share a single hardware.

[0042] In another example, service 114 can be deployed to container platform 210. The container platform differs from virtual machine 208 in several important ways. First, container platform 210 packages individual services into containers, as shown below. Figure 3This is described in more detail below. Each container shares the host operating system kernel, and they also share binaries, libraries, and other read-only components. This makes containers very lightweight – often only a few megabytes in size. Furthermore, lightweight containers are very efficient, starting in just a few seconds, compared to minutes for booting a virtual machine. Containers also reduce management overhead by sharing the operating system and other libraries that can be maintained together for the entire collection of containers in the Container Platform 210. Although containers share the same operating system, they provide an isolated platform because the operating system provides virtual memory support for isolation. Container technology can include... Containers, Linux Open Container Initiative (OCI) CoeOS Mesos, etc. These containers can be deployed to a container orchestration platform, which can be simply referred to as a "container platform" in this document. 210 The container platform manages the automated deployment, coordination, and management of deployed software containers. 210 The container platform can provide service discovery, load balancing, health checks, multiple deployments, etc. 210 The container platform can be implemented by any publicly available container platform (such as Kubernetes) that runs containers organized in nodes and bays.

[0043] Regardless of the platforms 206, 208, and 210 on which service 114 is deployed, each of these platforms can provide service endpoints 212, 214, and 216 that provide public access for invoking service 114. Generally, these endpoints are accessible via HTTP calls and associated with IP addresses and port numbers. By connecting to the correct IP address and port number, other services can invoke the service deployed on any of platforms 206, 208, and 210 when they are publicly available. Each service (such as service 114) may include its own proprietary format and data requirements for invoking that service. Similarly, each service may return results specific to service 114 in terms of format and data type. In addition to service-specific requirements, specific deployment platforms 206, 208, and 210 may also include additional requirements for interacting with service 114, such as programming languages, data packet formats (JSON, XML, etc.) that need to be conformed to in order to correctly interact with the service.

[0044] While the above examples allow service 114 to be deployed to any of the platforms 206, 208, and 210, the embodiments described herein are specifically designed for the container platform 210 described above. Therefore, embodiments specifically described for deployment in a “container platform” can be distinguished from other embodiments specifically described for deployment in a virtual machine platform, a server or dedicated hardware platform, or generally in an IaaS environment.

[0045] Figure 3 The illustration shows data organization specific to container platform 210 used by some embodiments described herein. Generally, any deployment of services to the container platform will be deployed to bays 304, 306. A bay is an abstraction representing a group of one or more application containers (e.g., Docker or rkt). A bay may also include some shared resources that are typically available to all containers within that bay. For example, bay 304 includes containers 310 and 312. Bay 304 also includes shared resource 308. Resources may include storage volumes or other information about how containers run or connect within bay 304. Bay 304 can model a dedicated logical host containing relatively tightly coupled different service containers 310, 312. For example, service 326 in container 310 can utilize resource 308 and invoke service 320 in container 312. Service 320 can also invoke service 322, which in turn invokes service 324, each service deployed to container 312. The output of service 324 can be provided to a network IP address and port 318, another public resource shared by bay 304. Therefore, services 320, 322, 324, and 326 all work together with shared resource 308 to provide a single service that can be accessed by services running in other containers via IP address and port number 318. The service can also be accessed by computer systems outside the container platform (such as workstations, laptops, smartphones, or other computing devices not part of the container platform or IaaS environment) via IP address and port 318.

[0046] In the simplest deployment, each container can include a single service, and each cabin can include a single container encapsulating the service. For example, cabin 306 contains only a single container 314 with a single service 328. This single service can be accessed via cabin 306's IP address and port number 316. Typically, when a service is deployed to a container platform, containers and cabins are instantiated to maintain the service. Many different cabins can be deployed to container node 302. Generally, cabins run within a node. A node represents a worker machine (virtual or physical) in the container platform. Each node is managed by a "master device" that automatically handles scheduling cabins within each node. Each node can run processes responsible for communication between the master device and the node, and for managing cabins within containers on the machine represented by that node. Each node can also include a container runtime responsible for pulling container images from the registry, unpacking containers, and running services.

[0047] Figure 4The illustration shows an API registrar 404, which can be deployed to IDE 102 and production / deployment environment 104 according to some embodiments. As mentioned above, there is a technical problem where, when service 114 is deployed from IDE 102 to production / deployment environment 104, service 114 loses runtime access to information available only in IDE 102. API registrar 404 becomes accessible to service 114 when deployed and operated during runtime in production / development environment 104. By registering services with API registrar 404 during development and providing API definitions and / or API characteristics to API registrar 404, API registrar 404 overcomes the previous technical problem of isolation between development and runtime functionality. The information defining the API can be used by new services being developed in IDE 102 as well as services already deployed to production / deployment environment 104. After this registration process is completed, service 114 can operate using client libraries that access API registrar 404 during runtime to ensure that API functions are correctly bound to the current IP address and port number of the corresponding service. API registry 404 indicates a new data structure and processing unit specifically designed to solve these technical problems.

[0048] Another technical problem in the existing technology is implementing service features when deploying them to the production / development environment 104. For example, if a service with high availability is to be deployed, developers would need to build multiple instances of the service specifically instantiated in the container platform and balance the container deployment files of the business in a way that ensures the service is always available. Service developers do not always have this expertise, and they often cannot manage the deployment of their services. As described below, the API registrar 404 allows services to simply select features (such as high availability), which can then be automatically implemented by the API registrar 404. This technical solution is feasible because the API registrar 404 eliminates the barrier between the IDE 102 and the production / deployment environment 104.

[0049] Figure 5The illustration shows the deployment of an API registrar 404 used at runtime with a container platform 210 according to some embodiments. One of the technical solutions and improvements over the prior art provided by the API registrar 404 is the maintenance of stable endpoints for service calls, and the simplified and automated code generation for accessing service calls. Prior to this disclosure, calls between services were point-to-point connections, for example, using HTTP calls to IP addresses and port numbers. As services are updated, replaced, relocated, and redeployed in the container platform 210, IP addresses and port numbers may change frequently. This requires all services calling the updated service to update their IP addresses and port numbers in the actual code calling that service. The API registrar 404 solves this technical problem by providing dynamic binding between the IP addresses and port numbers of services and the API functions available through the API registrar. The client library automatically generated by the API registrar 404 may include functionality to access the API registrar 404 to retrieve and / or verify the current IP address and port number for a specific service. Therefore, a first service connecting to a second service only needs to perform client library generation once to provide a stable connection to the second service throughout its lifecycle.

[0050] Another technical problem addressed by API Registry 404 is the automatic generation of client libraries. Prior to this disclosure, accessing a second service from a first service required developers to write custom code for accessing the second service. Because this code could change over time, incompatibility between the first and second services could increase, necessitating updates to both services. API Registry 404 solves this problem by uploading API definition files that automatically generate client libraries for calling services. Therefore, services can specify how calling code in any other service should operate, ensuring compatibility. These client libraries also significantly simplify and encapsulate the code used to call services. As described below, complex HTTP calls using IP addresses and port numbers can be replaced with simple member function calls in a language specific to the calling service (e.g., Java, C#, etc.). This allows the calling service to select API functions from API Registry 404, and the code implementing those functions can be downloaded to the calling service as a client library.

[0051] Figure 6AA flowchart illustrating a method for deploying an API registrar 404 according to some embodiments is shown. The method may include deploying the API registrar service to a container environment (601). The API registrar may be implemented as a service operating within a container environment. Therefore, after the service is deployed to the container environment, the API registrar can run proactively, making it accessible at runtime. The API registrar may also be linked to the existing IDE described above. The method may also include discovering ports for available services within the container platform (603). When a service is deployed to the container platform, the API registrar may initiate a discovery process that sequentially traverses each service deployed to the container platform. For each service, the API registrar may detect and record the IP address and port number. The list of IP addresses and port numbers discovered through this process may be stored in a data structure, such as in a table associated with the API registrar. Each IP address and port number may also be stored along with the service name or other identifier that uniquely identifies the service on the container platform. Figure 6A The initial steps shown in the flowchart provide the API registrar with a starting point to begin operating in the container platform's runtime environment and to be used by services being developed in the IDE.

[0052] Figure 6B The illustration shows, according to some embodiments, when using Figure 6A The flowchart above illustrates the software architecture of container platform 210 when deploying the API registrar. As described above, API registrar 404 can be deployed to container 620 within container platform 210. Container 620 can operate within one or more compartments and within nodes, as described above. Figure 3 As described above, API Registrant 404 can be dedicated to any of the other containers in Container Platform 210. In some embodiments, API Registrant 404 can also be made available to other devices that are not part of Container Platform 210. As a containerized service, API Registrant 404 can have IP addresses and port numbers that can be used by other services. However, the IP address and port number of API Registrant 404 will only be used by code automatically generated in the client library, so some embodiments do not require the IP address and port number of API Registrant 404 to be published. Instead, the client library in the IDE itself can maintain an up-to-date list of the IP address and port number of API Registrant 404, making it accessible during the development, deployment, and runtime of other services.

[0053] After deploying API Registrar 404 to container 620, API Registrar 404 can perform a discovery process. This discovery process uses a directory listing of nodes in the container platform to identify service implementations based on IP addresses and port numbers. API Registrar 404 can then access unique identifiers (such as a number or name for each available service) and store these identifiers with each IP address and port number in container platform 210. This discovery process can be performed periodically to detect new services added to container platform 210 and to identify existing services removed from container platform 210. As described below, this discovery process can also be used to detect when the IP address and port number of an existing service changes. For example, API Registrar 404 can discover services with endpoints 602, 604, 606, and 608. In the process described below, API Registrar 404 can bind each of these endpoints 602, 604, 606, and 608 to an API function registered with API Registrar 404. At some point after this initial discovery, when the service associated with endpoint 602 is replaced, updated, or revised, the IP address and / or port number of endpoint 602 may change. API registrar 404 can detect such a change to endpoint 602 and update the bindings to existing API functions provided by API registrar 44.

[0054] Similarly, API registrar 404 can use a discovery process to detect when an endpoint is no longer available and then remove the API function associated with the service. In some embodiments, when a service has been registered with API registrar 404, but the corresponding API function is not currently bound to a valid endpoint, API registrar 404 can provide a mock response to any service that calls the corresponding API function. For example, if an API has been registered for the service corresponding to endpoint 604, but endpoint 604 is currently unavailable, then API registrar 404 can intercept calls to endpoint 604 and provide default or pseudo-data as a response. This allows services that call the service associated with endpoint 604 to maintain functionality and / or continue the design process without “disconnecting” from this particular service. The mock / test data scenario will be described in more detail below.

[0055] Figure 7AThe diagram illustrates a flowchart of a method for registering a service with an API registrar 404 according to some embodiments. The method may include receiving an upload of an API definition (701). The API definition may be provided in the form of data packets, files, or links to an information repository. The API definition may include any information that can be used to identify and define the API functions that should be bound to the endpoint associated with the service. For example, some embodiments of the API definition may include the following data: service name or other unique identifier; function name corresponding to the service endpoint and the call; data input required to call the service, along with corresponding descriptions and data types; result data format and data type; current IP address and / or port number; documentation describing the functionality of the API function associated with the endpoint; default or pseudo-data values ​​that should be returned during a virtual / test scenario; and any other information that the API registrar 404 can use to translate HTTP requests received by the endpoint into API function calls using data-like objects.

[0056] This method may also include creating corresponding API functions based on the uploaded API definition (703). These API functions can be automatically generated based on the API definition. Each endpoint of a service can be associated with multiple different API functions. For example, endpoints implementing a RESTful interface can receive HTTP calls to the POST, GET, PUT, and DELETE functions at the same IP address and port number. This may result in different API functions. For example, if the interface represents a list of users, then this list can correspond to at least four different API functions, such as GetUser(), AddUser(), RemoveUser(), and UpdateUser(). Furthermore, each API function can include multiple different lists of parameters, such as UpdateUser(id), UpdateUser(name), UpdateUser(firstname, lastname), etc. These API functions can be generated and made available to other services through the API registry. As will be described in more detail below, it should be noted that services are not required to call these functions through the API registry. Instead, these functions can be browsed in the API registry, and when selected, the API registry can generate client libraries that implement these functions in the calling service.

[0057] This method can additionally include creating bindings between corresponding endpoints of API functions and services in the API registrar (705). Based on the discovery process described above and the registration process in step 701, the API registrar can now create dynamic bindings between endpoints of services in the container platform and API functions created by the API registrar. In the data structure formed when discovering available endpoints and services above, the API registrar can now store the corresponding function or set of functions for each endpoint. As mentioned above, this binding can be continuously updated as the discovery process determines when a service is updated, moved, replaced, or added to the container platform. This allows client libraries created in calling the service to first check the API registrar to verify or receive the current IP address and port number used for that service.

[0058] Figure 7B The illustration shows a hardware / software diagram illustrating the steps for registering an API with an API registrar 404 according to some embodiments. As described above, the API registrar 404 can be instantiated and run in container 620 within container platform 210. Even if container platform 210 represents a production / deployment environment, API registrar 404 can still be accessed by IDE 102 for developing services. Therefore, IDE 102 can provide a mechanism for uploading API definition files 702 to API registrar 404. Specifically, the user interface of IDE 102 may include a window or interface that allows developers to define and / or populate fields for API definition files 702. Such information described above may include function names, parameter lists, data types, field lengths, object class definitions, IP addresses and port numbers, service names, or other unique identifiers. This information can be uploaded to API registrar 404 and dynamically linked to a specific IP address and port number of endpoint 602. Finally, API registrar 404 can generate one or more API functions 704 that are available through API registrar 404.

[0059] After a service is registered with the API Registry with a 404 error and one or more API functions are generated, the API Registry can make these functions available to developers when they design the service. Figure 8 Examples of graphical interfaces 802 and command-line interfaces 804, according to some embodiments, are illustrated for browsing and selecting APIs registered with API registrars 804. When programming for container platforms and developing new services, developers can access graphical interface 802 to browse and select API functions that can be used in their services. This graphical interface 802 is merely an example and is not intended to limit the types of graphical interfaces that can be used to browse and select API functions.

[0060] In this embodiment, IDE 102 can summon graphical interface 802 to provide a list of APIs registered with the API registrar. In this embodiment, APIs are categorized based on endpoints. For example, an endpoint corresponding to a service may provide a RESTful interface for storing user records (e.g., "UserStorage"). Graphical interface 802 can display all API functions available through the selected endpoint (e.g., "CreateUser", "DeleteUser", "UpdateUser", etc.). In cases where the service provides multiple endpoints, other embodiments may group functions based on the entire service. Graphical interface 802 can receive a selection of one or more API functions to be used when invoking the service. The API registrar can then provide documentation explaining how to use the API functions, including required parameters and return values. Those skilled in the art will understand that command-line interface 804 can provide similar information and receive similar input to graphical interface 802.

[0061] Figure 8 Interfaces 802 and 804, as shown, offer several technical advantages. First, these interfaces 802 and 804 provide an up-to-date list of all APIs registered with the API registrar. This corresponds to a list of all currently available services in the container platform. Service developers can retrieve and display this information in real time, instead of needing to consult documentation, contact service developers, and / or perform other inefficient tasks to locate the list of available services. Furthermore, as services are updated, the API definition files can be updated accordingly. This update... Figure 8 The display shown is intended to provide up-to-date availability information for each API function.

[0062] Figure 9 The diagram illustrates a flowchart, according to some embodiments, of a method for using services registered with an API registrar and their corresponding functions. The method may include providing a list of registered APIs (901). This step can be omitted if the desired service is known. However, in general, the above method can be used. Figure 8 The interface described herein is used to display the service for browsing and navigation. The method may also include receiving a selection of an API function (901). The API registrar can receive this selection from the service developer. For example, the developer might decide to use the CreateUser() function described above to update the database of user records. Figure 10 The illustration shows how the API registrar can receive selections 1002 via a graphical interface 802 used in the CreateUser() function. Other embodiments may receive selections via a command-line interface or other input methods provided by the IDE.

[0063] Return to reference Figure 9 Once a selection of an API function is received, the API registrar can generate one or more client libraries for the calling service (905). Generating client libraries can provide the calling service with a service endpoint dynamically bound to the API function. Specifically, the IDE can generate a collection of class objects within the IDE, which encapsulate the functionality required to interface directly with the service endpoint in the container platform. In some embodiments, the client library may include object classes that can be instantiated or used to invoke member functions required to implement code for communicating with the service. Examples of such client libraries are described in more detail below.

[0064] This method may additionally include providing test data (907). When a service registers with the API registry, it does not need to be complete. Instead, the service can indicate to the API registry that it is not yet ready to provide a function response to the service call. In some embodiments, the API definition file uploaded to the API registry may include specifications of the types of information that should be returned before the service takes effect. When the service calls an API function, a client library generated by the API registry can route the request to the API registry instead of the service endpoint. The API registry can then provide a response using pseudo-values, null values, or default values. Alternatively, the code within the client library itself can generate default data to return to the calling service.

[0065] It should be recognized that, Figure 9 The specific steps shown provide specific methods for using an API registrar according to various embodiments of the present invention. According to alternative embodiments, other sequences of steps may also be performed. For example, alternative embodiments of the invention may perform the steps outlined above in a different order. Furthermore, Figure 9 The steps shown may include multiple sub-steps, which may be performed in various orders suitable for the individual steps. Furthermore, depending on the specific application, additional steps may be added or removed. Those skilled in the art will recognize many variations, modifications, and alternatives.

[0066] Figure 11 The illustration shows an example of a client library automatically generated for a service by an API registrar according to some embodiments. This client library 1102 may correspond to a service that stores user records. This client library 1102, along with its corresponding classes and services, is provided by way of example only and is not intended to be limiting. As mentioned above, each API function and service can specify how the client library should be generated from the API definition file uploaded to the API registrar. Therefore, the principles described below regarding the "User" service can be applied to other services.

[0067] To represent the "User" service, the API registrar can generate a class for User. When a service requests the API registrar to generate a client library, the service can specify the programming language it uses. For example, if the service is written in Java within an IDE, the API registrar can generate a class library in Java. Alternatively, if the service is written in C#, the API registrar can generate a class library in C#. The User class can be generated with member functions corresponding to different operations that can be performed through the service endpoint. These member functions can be static, so that they do not require an instance of the User class, or they can be used with an instantiated User object.

[0068] In this example, the User service can edit individual user records stored by the service using a RESTful interface. For example, the API registrar can generate a CreateUser() function to implement a POST call to the User service. One of the functions that the library can perform is parsing, filtering, and formatting data provided as parameters to the API function so that it can be sent directly to the service as data packets. In this example, the CreateUser() function can accept parameters formatted for convenient service invocation. For example, the service can store the user's first name and last name as separate strings. However, a POST command might require a concatenated string of first and last names. To accommodate user-friendly parameter sets, client library 1102 can perform setup operations that format the data received as function parameters into a format compatible with the server endpoint. This can include generating header information, changing the format of certain data fields, concatenating data fields, requesting additional data from other sources, performing calculations or data transformations, etc. It can also include packaging reformatted parameters into formats such as JSON, XML, etc.

[0069] Once the parameters are correctly formatted into the packet used for the service endpoint, client library 1102 can also handle POST calls to the service. When the client library is generated, the service's IP address and port number can be inserted into the `CreateUser()` function for use in HTTP requests to the service. Note that the details of the HTTP request are encapsulated within the `CreateUser()` function. When developers calling the service want to use the POST functions available through the service instead of writing code themselves in library 1102, they can instead select the "User" service from the API registry. The API registry will then automatically generate client library 1102, which includes the `User` class. Then, to use the POST functions, service developers can simply use the `User.CreateUser("John", "Smith", 2112)` function to add the user John Smith to the service.

[0070] Figure 12 The illustration depicts an embodiment of a client library 1202 that adapts to the dynamic binding between a service endpoint and an API function, according to some embodiments. In this example, when the API registrar generates client library 1202, the CreateUser() function may include code 1204 that dynamically retrieves the IP address and port number of the service. When service 114 is operating in a production / deployment environment 104 (such as a container platform), service 114 can send a request to API registrar 404 at runtime using the GetIPPort() function. API registrar 404 can access its internal tables, which are consistently updated to maintain the latest binding between the API function and the service endpoint. API registrar 404 can then return the current IP address and port number to service 114. Client library 1202 can then insert the IP address and port number into an HTTP POST code to connect to the service. Because API registrar 404 can be accessed at runtime by any calling service in the container platform, there is no need to update or patch services when the IP address or port number of the called service changes. Instead, API registrar 404 can provide the latest information each time a service is called. In some embodiments, assuming that the service endpoint does not change frequently in the production environment, the GetIPPort() function may only need to call the API registry 404 once per hour, once per day, once per week, etc., to minimize the number of function calls made outside the container for service 114.

[0071] Figure 13An embodiment of a client library 1302 according to some embodiments is illustrated, which can organize additional data to complete the input dataset for service invocation. To simplify the use of client library 1302, it can minimize the number of parameters required by service developers. Additional data required for service invocation can be retrieved from other sources and therefore can be omitted from the parameter list. Alternatively, client library 1302 can retrieve these additional parameters directly from these other sources. For example, creating a new user can include specifying user roles for that user. Instead of requiring service developers to provide user roles as one of the parameters, client library 1302 can instead include code 1304 that automatically retrieves the user's roles from some other source. In this example, the user roles can be retrieved from a database, from another service in a container platform, or from another class that stores user roles within the invoking service. In any of these cases, code 1304 can automatically retrieve the user roles and package them as part of the input data sent to the service via an HTTP POST command.

[0072] In addition to tidying and formatting the data input to the service, client library 1302 can also parse and return data received from the service and handle error conditions. In this example, the POST command can return data in groups to the Result variable. Services often return data groups containing more information than is required to call the service. Therefore, client library 1302 can parse the data fields in the Result variable, extract and format the data from the Result variable, and package the data from the Result variable into a more usable and expected format for the User class. In this example, code 1306 can extract fields from the Result variable and use them to create a new User object returned from the API function. In another example using the GET command, various API functions can be generated in the User class that extract different fields from the Result variable from the GET command. For example, the User class could provide functions like GetFirstName(id), GetLastName(id), GetRole(id), etc. Each of these functions could include very similar code while returning different fields from the Result variable.

[0073] In addition to parsing the results, client library 1302 can also generate code 1308 to handle error conditions associated with using the service. In this example, code 1308 can test the status field in the Result variable to determine whether the POST command was successful. If the command succeeds, the CreateUser() function can return a new User object. In the event that the POST command fails, the function can instead return an empty object and / or retry the call to the service.

[0074] Figure 14 The illustration shows a client library 1402 that can handle retries when invoking a service, according to some embodiments. Like... Figure 13 Similar to the previous example, client library 1402 uses the status in the Result variable populated by the POST HTTP call to determine whether the call was successful. If the result is unsuccessful, client library 1402 can continue to retry until the call succeeds. Some embodiments may use a counter or other mechanisms to limit the number of retries or add a wait time between retries.

[0075] Each method described herein can be implemented by a dedicated computer system. Each step of these methods can be executed automatically by the computer system and / or can be provided with input / output involving a user. For example, a user can provide input for each step in the method, and each of these inputs can provide a specific output in response to a request for such input, wherein the output is generated by the computer system. Each input can be received in response to a corresponding requested output. Furthermore, input can be received from a user, received as a data stream from another computer system, retrieved from a memory location, retrieved via a network, requested from a web service, etc. Similarly, output can be provided to a user, provided as a data stream to another computer system, stored in a memory location, sent via a network, provided to a web service, etc. In short, each step of the methods described herein can be executed by a computer system and can involve any number of inputs, outputs, and / or requests from the computer system, which may or may not involve a user. Those steps that may be referred to as not involving a user are executed automatically by the computer system without human intervention. Therefore, it will be understood from this disclosure that each step of each method described herein can be modified to include input and output to and from the user, or can be performed automatically by a computer system without human intervention, wherein any determination is generated by the processor. Furthermore, some embodiments of each method described herein can be implemented as a set of instructions stored on a tangible, non-transient storage medium to form a tangible software product.

[0076] Figure 15A simplified diagram of a distributed system 1500 capable of interacting with any of the embodiments described above is depicted. In the illustrated embodiment, the distributed system 1500 includes one or more client computing devices 1502, 1504, 1506, and 1508, which can be configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), via one or more networks 1510. A server 1512 can be communicatively coupled to remote client computing devices 1502, 1504, 1506, and 1508 via network 1510.

[0077] In various embodiments, server 1512 may be adapted to run one or more services or software applications provided by one or more components of the system. In some embodiments, these services may be provided as web-based services or cloud services, or provided to users of client computing devices 1502, 1504, 1506, and / or 1508 under a Software as a Service (SaaS) model. Users operating client computing devices 1502, 1504, 1506, and / or 1508 may in turn use one or more client applications to interact with server 1512 to utilize the services provided by these components.

[0078] In the configuration illustrated in the figures, software components 1518, 1520, and 1522 of system 1500 are shown as being implemented on server 1512. In other embodiments, one or more components of system 1500 and / or the services provided by these components may also be implemented by one or more of client computing devices 1502, 1504, 1506, and / or 1508. A user operating the client computing device can then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be recognized that various different system configurations are possible and may differ from the distributed system 1500. The embodiment shown in the figures is therefore an example of a distributed system for implementing the embodiment system and is not intended to be limiting.

[0079] Client computing devices 1502, 1504, 1506, and / or 1508 can be portable handheld devices (e.g., Cellular phone Computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google) Head-mounted displays (or similar devices) that run Microsoft Windows And / or software such as various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS, etc.), and with internet access, email, and short message service (SMS) enabled. Or other communication protocols. The client computing device can be a general-purpose personal computer, for example, including those running various versions of Microsoft... Apple Personal computers and / or laptops running Linux operating systems. Client computing devices can be running various commercially available operating systems. Workstation computers running any operating system, such as GNU / Linux operating systems (including, but not limited to, various GNU / Linux operating systems, such as Google Chrome OS). Alternatively or additionally, client computing devices 1502, 1504, 1506, and 1508 may be any other electronic device capable of communicating via one or more networks 1510, such as thin client computers, internet-enabled gaming systems (e.g., with or without...). The gesture input device is the Microsoft Xbox game console and / or a personal messaging device.

[0080] Although the exemplary distributed system 1500 is shown as having four client computing devices, any number of client computing devices can be supported. Other devices (such as devices with sensors) can interact with server 1512.

[0081] The network(s)1510 in the distributed system 1500 can be any type of network familiar to those skilled in the art, capable of supporting data communication using any of a variety of commercially available protocols, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Switching), AppleTalk, etc. By way of example only, the network(s)1510 can be a local area network (LAN), such as a LAN based on Ethernet, Token Ring, etc. The network(s)1510 can be a wide area network and the Internet. It can include virtual networks, including but not limited to Virtual Private Networks (VPNs), intranets, extranets, Public Switched Telephone Networks (PSTN), infrared networks, wireless networks (e.g., according to the IEEE 802.11 protocol suite), (and / or any other wireless protocol operating network); and / or any combination of these and / or other networks.

[0082] Server 1512 may include one or more general-purpose computers, special-purpose server computers (as an example, including PC (personal computer) servers, etc.). Servers (including mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable arrangement and / or combination. In various embodiments, server 1512 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 1512 may correspond to a server used to perform the processes described above according to embodiments of this disclosure.

[0083] Server 1512 can run any of the operating systems discussed above, as well as any commercially available server operating system. Server 1512 can also run any of a variety of additional server applications and / or middleware applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, etc. Servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available database servers from Oracle, Microsoft, Sybase, IBM, etc.

[0084] In some implementations, server 1512 may include one or more applications to analyze and integrate data feeds and / or event updates received from users of client computing devices 1502, 1504, 1506, and 1508. As an example, data feeds and / or event updates may include, but are not limited to, those provided in the original text. feed, The server 1512 may update or receive real-time updates and continuous data streams from one or more third-party information sources, which may include real-time events related to sensor data applications, financial quotation machines, network performance measurement tools (e.g., network monitoring and business management applications), clickstream analysis tools, vehicle traffic monitoring, and the like. The server 1512 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of client computing devices 1502, 1504, 1506, and 1508.

[0085] The distributed system 1500 may also include one or more databases 1514 and 1516. Databases 1514 and 1516 may reside in various locations. As an example, one or more of databases 1514 and 1516 may reside on non-transient storage media local to server 1512 (and / or residing within server 1512). Alternatively, databases 1514 and 1516 may be located remotely from server 1512 and communicate with server 1512 via a network-based connection or a dedicated connection. In one set of embodiments, databases 1514 and 1516 may reside in a storage area network (SAN). Similarly, any necessary files for performing the functions of server 1512 may be appropriately stored locally on server 1512 and / or remotely. In one set of embodiments, databases 1514 and 1516 may include relational databases, such as those provided by Oracle, adapted to store, update, and retrieve data in response to commands in SQL format.

[0086] Figure 16 This is a simplified block diagram of one or more components of a system environment 1600 according to an embodiment of the present disclosure, through which services provided by one or more components of the embodiment system can be provided as cloud services. In the illustrated embodiment, system environment 1600 includes one or more client computing devices 1604, 1606, and 1608 that can be used by a user to interact with a cloud infrastructure system 1602 providing cloud services. The client computing devices can be configured to operate client applications, such as web browsers, proprietary client applications (e.g., Oracle Forms), or some other application, which can be used by the user of the client computing devices to interact with the cloud infrastructure system 1602 to use services provided by the cloud infrastructure system 1602.

[0087] It should be recognized that the cloud infrastructure system 1602 depicted in the figures may have other components besides those depicted. Furthermore, the embodiment shown in the figures is merely one example of a cloud infrastructure system that can be incorporated into embodiments of the present invention. In some other embodiments, the cloud infrastructure system 1602 may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations or arrangements.

[0088] Client computing devices 1604, 1606, and 1608 can be devices similar to those described above for 1502, 1504, 1506, and 1508.

[0089] While the exemplary system environment 1600 is shown with three client computing devices, any number of client computing devices can be supported. Other devices, such as those with sensors, can interact with the cloud infrastructure system 1602.

[0090] One or more networks 1610 can facilitate data communication and exchange between clients 1604, 1606, and 1608 and cloud infrastructure system 1602. Each network can be any type of network that supports data communication and is familiar to those skilled in the art, using any of a variety of commercially available protocols, including those described above for one or more networks 1510.

[0091] The cloud infrastructure system 1602 may include one or more computers and / or servers, which may include those computers and / or servers described above for server 1512.

[0092] In some embodiments, services provided by a cloud infrastructure system may include a variety of services available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. Services provided by a cloud infrastructure system can be dynamically scaled to meet the needs of users of the cloud infrastructure system. A specific instantiation of a service provided by a cloud infrastructure system is referred to herein as a "service instance." Generally, any service available to users from a cloud service provider's system via a communication network (such as the Internet) is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that constitute the cloud service provider's system differ from the servers and systems deployed on-premises by the customer. For example, a cloud service provider's system may host applications, and users may subscribe to and use these applications on demand via a communication network such as the Internet.

[0093] In some examples, services within a computer network cloud infrastructure may include protected computer network access to storage devices, hosted databases, hosted web servers, software applications, or other services provided to users by the cloud provider, or as otherwise known in the art. For example, services may include password-protected access to remote storage devices in the cloud via the Internet. As another example, services may include web-based hosted relational databases and scripting language middleware engines for private use by networked developers. As yet another example, services may include access to email software applications hosted on a cloud provider's website.

[0094] In some embodiments, cloud infrastructure system 1602 may include a suite of application, middleware, and database service products delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle public cloud provided by this assignee.

[0095] In various embodiments, cloud infrastructure system 1602 can be adapted to automatically provision, manage, and track customer subscriptions to services provided by cloud infrastructure system 1602. Cloud infrastructure system 1602 can provide cloud services via different deployment models. For example, services can be provided under a public cloud model, in which cloud infrastructure system 1602 is owned by an organization selling cloud services (e.g., owned by Oracle), and the services are available to the general public or businesses in different industries. As another example, services can be provided under a private cloud model, in which cloud infrastructure system 1602 operates only for a single organization and can provide services to one or more entities within that organization. Cloud services can also be provided under a community cloud model, in which cloud infrastructure system 1602 and the services provided by cloud infrastructure system 1602 are shared by several organizations in the relevant community. Cloud services can also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0096] In some embodiments, the services provided by the cloud infrastructure system 1602 may include one or more services offered under the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category, the Infrastructure as a Service (IaaS) category, or other service categories that include hybrid services. A customer may subscribe to one or more services provided by the cloud infrastructure system 1602 via a subscription order. The cloud infrastructure system 1602 then performs processing to deliver the services in the customer's subscription order.

[0097] In some embodiments, the services provided by the cloud infrastructure system 1602 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall into the SaaS category. For example, a SaaS platform may provide the ability to build and deliver on-demand application suites on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure used to provide SaaS services. By utilizing the services provided by the SaaS platform, customers can leverage applications running on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services providing solutions for sales performance management, enterprise integration, and business agility for large organizations.

[0098] In some embodiments, platform services may be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services that fall into the PaaS category. Examples of platform services may include, but are not limited to, services that enable organizations (such as Oracle) to integrate existing applications on a shared, public architecture and to leverage the shared services provided by the platform to build new applications. The PaaS platform can manage and control the underlying software and infrastructure used to provide PaaS services. Customers can access PaaS services provided by the cloud infrastructure system without having to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.

[0099] By leveraging services provided by a PaaS platform, customers can employ programming languages ​​and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware Service), and Java cloud services. In one embodiment, the database cloud service may support a shared services deployment model, which enables organizations to aggregate database resources and provide database-as-a-service to customers in the form of a database cloud. Within the cloud infrastructure system, the middleware cloud service provides customers with a platform for developing and deploying various business applications, and the Java cloud service provides customers with a platform for deploying Java applications.

[0100] Various infrastructure services can be provided by IaaS platforms within cloud infrastructure systems. Infrastructure services facilitate the management and control of underlying computing resources (such as storage devices, networks, and other basic computing resources) for customers to utilize services provided by SaaS and PaaS platforms.

[0101] In some embodiments, the cloud infrastructure system 1602 may also include infrastructure resources 1630 for providing resources to customers of the cloud infrastructure system for delivering various services. In one embodiment, infrastructure resources 1630 may include a combination of pre-integrated and optimized hardware (such as servers, storage devices, and networking resources) to perform services provided by PaaS platforms and SaaS platforms.

[0102] In some embodiments, resources in cloud infrastructure system 1602 can be shared by multiple users and dynamically reallocated as needed. Furthermore, resources can be allocated to users in different time zones. For example, cloud infrastructure system 1630 can enable a first group of users in a first time zone to utilize the resources of the cloud infrastructure system for a specified number of hours, and then enable the same resources to be reallocated to another group of users located in a different time zone, thereby maximizing resource utilization.

[0103] In some embodiments, multiple internal shared services 1632 may be provided, shared by different components or modules of the cloud infrastructure system 1602 and by services provided by the cloud infrastructure system 1602. These internal shared services may include, but are not limited to: security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, cloud-enabled services, email services, notification services, file transfer services, etc.

[0104] In some embodiments, cloud infrastructure system 1602 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) within the cloud infrastructure system. In one embodiment, cloud management functionality may include the ability to provision, manage, and track customer subscriptions received by cloud infrastructure system 1602.

[0105] In one embodiment, as illustrated in the figure, cloud management functionality may be provided by one or more modules, such as an order management module 1620, an order orchestration module 1622, an order supply module 1624, an order management and monitoring module 1626, and an identity management module 1628. These modules may include or be provided using one or more computers and / or servers, which may be general-purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0106] In exemplary operation 1634, a customer using a client device (such as client device 1604, 1606, or 1608) can interact with cloud infrastructure system 1602 by requesting one or more services provided by cloud infrastructure system 1602 and placing subscription orders for one or more services provided by cloud infrastructure system 1602. In some embodiments, the customer can access cloud user interfaces (UIs) (cloud UI 1612, cloud UI 1614, and / or cloud UI 1616) and place subscription orders via these UIs. Order information received by cloud infrastructure system 1602 in response to a customer placing an order may include information identifying the customer and the one or more services provided by cloud infrastructure system 1602 that the customer wishes to subscribe to.

[0107] After a customer places an order, the order information is received via cloud UI 1612, 1614 and / or 1616.

[0108] At operation 1636, the order is stored in order database 1618. Order database 1618 can be one of several databases operated by cloud infrastructure system 1618 and operating together with other system components.

[0109] At operation 1638, the order information is forwarded to the order management module 1620. In some cases, the order management module 1620 can be configured to perform order-related billing and accounting functions, such as verifying the order and reserving the order after verification.

[0110] At operation 1640, order information is transmitted to order orchestration module 1622. Order orchestration module 1622 can use the order information to orchestrate services and supply resources for customer orders. In some cases, order orchestration module 1622 can use the services of order supply module 1624 to orchestrate resource supply to support subscribed services.

[0111] In some embodiments, the order orchestration module 1622 enables the management of business processes associated with each order and applies business logic to determine whether an order should continue to be supplied. At operation 1642, upon receiving a new subscription order, the order orchestration module 1622 sends a request to the order supply module 1624 to allocate resources and configure those resources required to fulfill the subscription order. The order supply module 1624 enables the allocation of resources for the services ordered by the customer. The order supply module 1624 provides an abstraction layer between the cloud services provided by the cloud infrastructure system 1600 and the physical implementation layer for supplying the resources used to provide the requested services. Therefore, the order orchestration module 1622 can be isolated from implementation details such as whether services and resources are actually supplied on demand or pre-supplied and allocated / assigned only upon request.

[0112] At operation 1644, once services and resources are supplied, notifications of the supplied services can be sent to customers on client devices 1604, 1606, and / or 1608 via the order supply module 1624 of the cloud infrastructure system 1602.

[0113] At operation 1646, the order management and monitoring module 1626 can manage and track customer subscription orders. In some cases, the order management and monitoring module 1626 can be configured to collect service usage statistics in subscription orders, such as storage usage, data transfer volume, number of users, system uptime, and system downtime.

[0114] In some embodiments, the cloud infrastructure system 1600 may include an identity management module 1628. The identity management module 1628 may be configured to provide identity services, such as access management and authorization services within the cloud infrastructure system 1600. In some embodiments, the identity management module 1628 may control information about customers who wish to utilize services provided by the cloud infrastructure system 1602. Such information may include information authenticating the identities of these customers and information describing what actions these customers are authorized to perform relative to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The identity management module 1628 may also include management of descriptive information about each customer and how and by whom that descriptive information can be accessed and modified.

[0115] Figure 17 An exemplary computer system 1700 in which various embodiments of the present invention can be implemented is shown. System 1700 can be used to implement any of the computer systems described above. As shown, computer system 1700 includes a processing unit 1704 that communicates with a plurality of peripheral subsystems via a bus subsystem 1702. These peripheral subsystems may include a processing acceleration unit 1706, an I / O subsystem 1708, a storage subsystem 1718, and a communication subsystem 1724. Storage subsystem 1718 includes a tangible computer-readable storage medium 1722 and system memory 1710.

[0116] Bus subsystem 1702 provides a mechanism for allowing various components and subsystems of computer system 1700 to communicate with each other as intended. While bus subsystem 1702 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1702 can be any of several types of bus structures using any bus architecture across a variety of bus architectures, including memory buses or memory controllers, peripheral buses, and local buses. For example, such architectures may include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses, which may be implemented as Mezzanine buses manufactured according to the IEEE P1386.1 standard.

[0117] A processing unit 1704, which may be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of the computer system 1700. One or more processors may be included in the processing unit 1704. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 1704 may be implemented as one or more independent processing units 1732 and / or 1734, each including a single-core or multi-core processor. In other embodiments, the processing unit 1704 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0118] In various embodiments, processing unit 1704 can execute various programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can reside in processor(s) 1704 and / or storage subsystem 1718. With appropriate programming, processor(s) 1704 can provide the various functions described above. Computer system 1700 may additionally include processing acceleration unit 1706, which may include digital signal processor (DSP), dedicated processor, etc.

[0119] The I / O subsystem 1708 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into a display, scroll wheels, click wheels, dials, buttons, switches, keyboards, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices, such as those from Microsoft... Motion sensors enable users to control devices such as Microsoft products via a natural user interface using gestures and voice commands. Input devices such as the 360 ​​Game Controller and interacting with them. User interface input devices may also include eye gesture recognition devices, such as detecting eye movements from the user (e.g., "blinking" when taking a photo and / or making a menu selection) and translating the eye gestures into the input device (e.g., Google). Google input in ) Blink detector. Additionally, the user interface input device may include enabling the user to interact with a voice recognition system (e.g., ...) via voice commands. Voice recognition sensing devices for interaction with navigators.

[0120] User interface input devices may also include, but are not limited to, 3D mice, joysticks or pointing sticks, gamepads and drawing tablets, as well as audio / video devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Furthermore, user interface input devices may include, for example, medical imaging input devices such as computed tomography (CT), magnetic resonance imaging (MRI), positron emission tomography (PET), and medical ultrasound equipment. User interface input devices may also include, for example, audio input devices such as MIDI keyboards and digital musical instruments.

[0121] User interface output devices may include display subsystems, indicator lights, or non-visual displays such as audio output devices, etc. Display subsystems may be cathode ray tubes (CRTs), flat panel devices such as those using liquid crystal displays (LCDs) or plasma displays, projection devices, touchscreens, etc. Generally, the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1700 to the user or other computers. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0122] Computer system 1700 may include a storage subsystem 1718 containing software elements, shown as currently located in system memory 1710. System memory 1710 may store program instructions that can be loaded and executed on processing unit 1704, as well as data generated during the execution of these programs.

[0123] Depending on the configuration and type of computer system 1700, system memory 1710 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that can be immediately accessed by processing unit 1704 and / or are currently being operated and executed by processing unit 1704. In some implementations, system memory 1710 may include various different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS) containing basic routines that facilitate the transfer of information between components of computer system 1700 during startup may typically be stored in ROM. As an example, but not a limitation, system memory 1710 also includes application programs 1712, program data 1714, and operating system 1716, which may include client applications, web browsers, middleware applications, relational database management systems (RDBMS), etc. As an example, operating system 1716 may include various versions of Microsoft... Apple and / or Linux operating system, and various commercially available... Or a UNIX-like operating system (including but not limited to various GNU / Linux operating systems, Google...) OS, etc.) and / or such as iOS, Phone OS 10OS and Mobile operating systems such as OS.

[0124] The storage subsystem 1718 may also provide a tangible computer-readable storage medium for storing basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provides the above-described functionality when executed by a processor may be stored in the storage subsystem 1718. These software modules or instructions may be executed by the processing unit 1704. The storage subsystem 1718 may also provide a repository for storing data used according to the present invention.

[0125] The storage subsystem 1700 may also include a computer-readable storage medium reader 1720 that can be further connected to the computer-readable storage medium 1722. Together with and optionally in conjunction with the system memory 1710, the computer-readable storage medium 1722 can comprehensively represent a remote, local, fixed, and / or removable storage device plus storage medium for temporarily and / or more persistently containing, storing, transmitting, and retrieving computer-readable information.

[0126] The computer-readable storage medium 1722, which contains code or portions thereof, may also include any suitable medium known or used in the art, including storage and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or other tangible computer-readable media. This may also include non-tangible computer-readable media such as data signals, data transmissions, or any other medium that can be used to transmit desired information and can be accessed by the computing system 1700.

[0127] As an example, computer-readable storage medium 1722 may include a hard disk drive that reads from or writes to a non-removable non-volatile magnetic medium, a disk drive that reads from or writes to a removable non-volatile disk, and a removable non-volatile optical disc drive (such as CD-ROM, DVD, etc.). An optical disc drive that reads from or writes to a removable, non-volatile optical disc (or other optical media). Computer-readable storage medium 1722 may include, but is not limited to, […]. Disk drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVDs, digital audio tapes, and so on. Computer-readable storage media 1722 may also include solid-state drives (SSDs) based on non-volatile memory (such as flash memory-based SSDs, enterprise flash drives, solid-state ROMs, etc.), volatile memory-based SSDs (such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs), and hybrid SSDs using a combination of DRAM-based and flash memory-based SSDs. Disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 1700.

[0128] The communication subsystem 1724 provides an interface to other computer systems and networks. The communication subsystem 1724 serves as an interface for receiving data from other systems and sending data from computer system 1700 to other systems. For example, the communication subsystem 1724 enables computer system 1700 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1724 may include radio frequency (RF) transceiver components, global positioning system (GPS) receiver components, and / or other components for accessing wireless voice and / or data networks, such as using cellular telephone technology, advanced data network technologies like 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof. In some embodiments, as an addition to or alternative to the wireless interface, the communication subsystem 1724 may provide a wired network connection (e.g., Ethernet).

[0129] In some embodiments, the communication subsystem 1724 may also represent one or more users who may use the computer system 1700 to receive input communications in the form of structured and / or unstructured data feeds 1726, event streams 1728, event updates 1730, etc.

[0130] As an example, the communication subsystem 1724 can be configured to receive data feeds 1726 in real time from users of the social network and / or other communication services, such as... feed, Updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0131] Furthermore, the communication subsystem 1724 can also be configured to receive data in the form of a continuous data stream, which may include event streams 1728 and / or event updates 1730 that are essentially continuous or unbounded real-time events without a clearly defined termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quotation machines, network performance measurement tools (e.g., network monitoring and business management applications), clickstream analysis tools, vehicle traffic monitoring, and so on.

[0132] The communication subsystem 1724 can also be configured to output structured and / or unstructured data feeds 1726, event streams 1728, event updates 1730, etc. to one or more databases, which can communicate with one or more streaming data source computers coupled to the computer system 1700.

[0133] The computer system 1700 can be one of various types, including handheld portable devices (e.g., Cellular phone Computing tablets, PDAs), and wearable devices (e.g., Google). Head-mounted displays, PCs, workstations, mainframes, information stations, server racks, or any other data processing systems.

[0134] Due to the ever-evolving nature of computers and networks, the description of the computer system 1700 depicted in the figures is merely a specific example. Many other configurations with more or fewer components than the system depicted in the figures are possible. For example, custom hardware may be used and / or specific elements may be implemented using hardware, firmware, software (including applets), or a combination thereof. Additionally, connections to other computing devices, such as network input / output devices, may also be employed. Based on the disclosure and teachings provided herein, those skilled in the art will recognize other ways and / or methods for implementing the various embodiments.

[0135] In the foregoing description, numerous specific details have been set forth for purposes of explanation in order to provide a thorough understanding of various embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are illustrated in block diagram form.

[0136] The foregoing description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of this disclosure. Rather, the foregoing description of the exemplary embodiments will provide those skilled in the art with enabling descriptions for implementing the exemplary embodiments. It should be understood that various changes can be made to the function and arrangement of the elements without departing from the spirit and scope of the invention as set forth in the appended claims.

[0137] Specific details have been set forth in the foregoing description to provide a thorough understanding of the embodiments. However, those skilled in the art will understand that these embodiments can be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may have been shown as components in block diagram form to avoid obscuring the embodiments with unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may have been shown without unnecessary detail to avoid obscuring the embodiments.

[0138] Furthermore, it should be noted that the various embodiments may be described as processes, depicted as flowcharts, schematic diagrams, structural diagrams, or block diagrams. While flowcharts may describe operations as sequential processes, many operations can be performed in parallel or simultaneously. Additionally, the order of operations can be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagram. Processes can correspond to methods, functions, programs, subroutines, subroutines, etc. When a process corresponds to a function, its termination can correspond to the function returning to the calling function or the main function.

[0139] The term "computer-readable medium" includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other media capable of storing, containing, or carrying one or more instructions and / or data. A code segment or machine-executable instruction can represent any combination of procedures, functions, subroutines, programs, routines, subroutines, modules, software packages, classes, or instructions, data structures, or program statements. A code segment can be coupled to another code segment or hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., can be passed, forwarded, or transmitted via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

[0140] Furthermore, embodiments can be implemented using hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments for performing the necessary tasks can be stored in a machine-readable medium. One or more processors can perform the necessary tasks.

[0141] In the foregoing specification, various aspects of the invention have been described with reference to specific embodiments thereof; however, those skilled in the art will recognize that the invention is not limited thereto. The various features and aspects disclosed above may be used individually or in combination. Furthermore, embodiments may be used in any number of environments and applications other than those described herein without departing from the broader spirit and scope of this specification. Accordingly, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

[0142] Furthermore, for illustrative purposes, the methods have been described in a specific order. It should be understood that, in alternative embodiments, the methods may be performed in a different order than described. It should also be understood that the methods described above can be executed by hardware components or can be implemented as a sequence of machine-executable instructions that can be used to cause a machine (such as a general-purpose or special-purpose processor or logic circuit programmed with instructions) to execute the methods. These machine-executable instructions can be stored on one or more machine-readable media, such as CD-ROMs or other types of optical discs, floppy disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, flash memory, or other types of machine-readable media suitable for storing electronic instructions. Alternatively, the methods can be executed by a combination of hardware and software.

Claims

1. A method for providing application programming interface (API) functions for registered service endpoints in a container environment, the method comprising: Receive requests from the second service to use the first service in a container environment at the API registry; The API registrar provides one or more API functions associated with the first service to the second service, wherein the one or more API functions are included as part of the second service to execute calls from the second service to the first service in a container environment; Receive requests for the endpoint of the first service from one or more API functions at the API registry; as well as An endpoint of a first service is provided by an API registrar and bound to one or more API functions, enabling one or more API functions in a second service to execute calls to the endpoint of the first service within a container environment.

2. The method of claim 1, wherein a request to use the first service is received from the second service in the development environment.

3. The method of claim 1, wherein a request for an endpoint of the first service is received from one or more API functions in a production environment.

4. The method of claim 1, further comprising: Receive the API definition at the API registrar, the API definition including: The endpoint of the first service encapsulated within a container deployed in a container environment; and One or more API functions; The API registrar creates a binding between the one or more API functions and the endpoint of the first service.

5. The method of claim 1, further comprising: After providing the one or more API functions to the second service, receive changes to the endpoint of the first service; as well as Before receiving the request from the one or more API functions, a new binding is created between the first service and the endpoint after the changes are made to the endpoint.

6. The method of claim 1, further comprising: Generate a client library for the second service, the client library including the one or more API functions.

7. The method of claim 6, wherein the client library comprises an object class having member functions that implement API functions.

8. The method of claim 6, wherein the client library includes direct calls to the endpoint of the first service.

9. The method of claim 6, wherein the client library reformatts the data received as one or more parameters of the one or more API functions into an HTTP call to the endpoint of the first service.

10. The method of claim 9, wherein the client library requests additional information from a third service to add to an HTTP call to the endpoint of the first service.

11. The method of claim 6, wherein the client library includes code to retry unsuccessful calls to the first service.

12. The method of claim 6, wherein the client library includes code that extracts result values ​​from the result set of the first service and packages the result values ​​into the return values ​​of the one or more API functions.

13. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: Receive requests from the second service to use the first service in a container environment at the API registry; The API registrar provides one or more API functions associated with the first service to the second service, wherein the one or more API functions are included as part of the second service to execute calls from the second service to the first service in a container environment; Receive requests for the endpoint of the first service from one or more API functions at the API registry; as well as An endpoint of a first service is provided by an API registrar and bound to one or more API functions, enabling one or more API functions in a second service to execute calls to the endpoint of the first service within a container environment.

14. The non-transient computer-readable medium of claim 13, wherein the endpoint of the first service comprises: IP address; as well as Port number.

15. The non-transient computer-readable medium of claim 13, wherein the container environment includes a plurality of services encapsulated in a container.

16. The non-transient computer-readable medium of claim 13, wherein the API registrar is deployed as a service encapsulated in a container within a container environment.

17. The non-transient computer-readable medium of claim 13, wherein the operation further comprises: The API registrar identifies any available endpoints of containerized services that have been deployed to a container environment.

18. A system for providing application programming interface (API) functions for registered service endpoints in a container environment, the system comprising: One or more processors; as well as A memory device including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: Receive requests from the second service to use the first service in a container environment at the API registry; The API registrar provides one or more API functions associated with the first service to the second service, wherein the one or more API functions are included as part of the second service to execute calls from the second service to the first service in a container environment; Receive requests for the endpoint of the first service from one or more API functions at the API registry; as well as An endpoint of a first service is provided by an API registrar and bound to one or more API functions, enabling one or more API functions in a second service to execute calls to the endpoint of the first service within a container environment.

19. The system of claim 18, wherein the operation further comprises: This allows a list of API functions for all services registered with the API registry to be displayed in the user interface.

20. The system of claim 19, wherein a request to use the first service is received from the second service by receiving a selection of one of the one or more API functions displayed in the user interface.

21. A method for providing application programming interface (API) functions for registered service endpoints in a container environment, the method comprising: The API registry receives a request from the second service to use the first service in a container environment, wherein the API registry lists one or more API functions that call the first service, and wherein the one or more API functions are bound to an endpoint of the first service. as well as An API registrar generates a client library for the second service, the client library including one or more API functions to execute calls from the second service to the first service in a container environment.

22. The method of claim 21, wherein the method further comprises: Receive requests for the endpoint of the first service from one or more API functions at the API registry; as well as The endpoint of the first service is provided by the API registrar, enabling one or more API functions in the second service to execute calls to the endpoint of the first service within the container environment.

23. The method of claim 21, wherein a request to use the first service is received from the second service in the development environment.

24. The method of claim 22, wherein a request for an endpoint of the first service is received from the one or more API functions in a production environment.

25. The method of claim 21, further comprising: Receive the API definition at the API registrar, the API definition including: The endpoint of the first service encapsulated within a container deployed in a container environment; and The one or more API functions; The API registrar creates a binding between the one or more API functions and the endpoint of the first service.

26. The method of claim 21, further comprising: After providing the client library to the second service, the changes to the endpoint of the first service are received; as well as Before receiving a request from the one or more API functions, a new binding is created between the first service and the endpoint after changes are made to the endpoint.

27. The method of claim 21, wherein the client library comprises an object class having member functions that implement API functions.

28. The method of claim 21, wherein the client library includes direct calls to the endpoint of the first service.

29. The method of claim 21, wherein the client library reformatts data received as one or more parameters of the one or more API functions into an HTTP call to the endpoint of the first service.

30. The method of claim 29, wherein the client library requests additional information from a third service to add to an HTTP call to the endpoint of the first service.

31. The method of claim 21, wherein the client library includes code to retry unsuccessful calls to the first service.

32. The method of claim 21, wherein the client library includes code that extracts result values ​​from the result set of the first service and packages the result values ​​as return values ​​of the one or more API functions.

33. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations including the following; The API registry receives requests from the second service to use the first service in a container environment, wherein the API registry lists one or more API functions that invoke the first service, and wherein said one or more API functions are bound to an endpoint of the first service; and An API registrar generates a client library for the second service, the client library including one or more API functions to execute calls from the second service to the first service in a container environment.

34. The non-transient computer-readable medium of claim 33, wherein the endpoint of the first service comprises: IP address; as well as Port number.

35. The non-transient computer-readable medium of claim 33, wherein the container environment includes a plurality of services encapsulated in a container.

36. The non-transient computer-readable medium of claim 33, wherein the API registrar is deployed as a service encapsulated in a container within a container environment.

37. The non-transient computer-readable medium of claim 33, wherein the operation further comprises: The API registrar identifies any available endpoints of containerized services that have been deployed to a container environment.

38. A system for providing application programming interface (API) functions for registered service endpoints in a container environment, the system comprising: One or more processors; as well as A memory device including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: The API registry receives a request from the second service to use the first service in a container environment, wherein the API registry lists one or more API functions that call the first service, and wherein the one or more API functions are bound to an endpoint of the first service. as well as An API registrar generates a client library for the second service, the client library including one or more API functions to execute calls from the second service to the first service in a container environment.

39. The system of claim 38, wherein the operation further comprises: This allows a list of API functions for all services registered with the API registry to be displayed in the user interface.

40. The system of claim 39, wherein a request to use the first service is received from the second service by receiving a selection of one of the one or more API functions displayed in the user interface.

Images