Methods, apparatuses, and systems for application programming interface servers

Abstract

This application relates to a method, apparatus, and system for an application programming interface server. An apparatus comprising a memory and a processor can be configured to perform techniques by which a runtime extensible application programming (API) server is provided. The memory can store a data store comprising data models. The processor can execute an API server by which the data models stored into the data store are accessed. The API server can receive a registration request from a controller to register a new data model into the data store (providing a resource definition specifying semantic validation rules), and register the new data model into the data store. The API server can next receive a creation request from a client to create a resource for the new data model with initial data conforming to the resource definition, apply the semantic validation rules to the initial data, and responsive to the validation, create the resource for the new data model in the data store.

Description

[0001] This application claims priority to U.S. Patent Application No. 17 / 446,923, filed September 3, 2021, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0002] The present disclosure relates to computer networks, and more specifically, to application programming interface servers within computer networks. BACKGROUND

[0003] A data center is a collection of interconnected computer servers and related components housed in one or more facilities. In a typical data center, a large collection of interconnected servers provide computing and / or storage capacity for the execution of various applications. For example, a data center can comprise a facility that hosts applications and services for users, i.e., customers of the data center. The data center can, for example, host all of the infrastructure equipment, such as network and storage systems, redundant power, and environmental controls. In most data centers, clusters of storage systems and application servers are interconnected by a high-speed switching fabric provided by one or more tiers of physical network switches and routers. More complex data centers provide infrastructure distributed around the world by user support equipment located in various physical hosting facilities.

[0004] A data center is typically composed of a large number of devices, including servers and equipment that make up an Internet Protocol (IP) fabric. The IP fabric can be represented as an underlay network with leaf devices and spine devices. In these larger data centers, a network controller or other network management device can coordinate network functions according to a business intent, which is then translated into network functions configured within the data center and supported by the IP fabric. A business network administrator can interface with the network controller to configure the underlay network into various topologies with certain functions to support the business intent (also referred to as an “intent”).

[0005] Such a network controller can include a distributed hierarchy of components, where the controller executes applications that deploy various topologies (e.g., 3-stage Clos, 5-stage Clos, hypercube, butterfly, etc.) or features (e.g., routing protocols, database structures— e.g., structured query language, graphs, proprietary, etc., quality of service, etc.) and manages an application programming interface (API) server that stores a data model representing the network topologies and features. The API server can perform semantic and syntactic validation with respect to the data model to ensure that data to be stored to the data model (according to the data model schema) is valid. The API server can facilitate the dynamic, real-time definition of network topologies that conform to the business intent, while also identifying updates, edits, creations, and / or deletions of data within the data model, alerting the controller of such modifications so that the controller can maintain the topologies deployed within the IP fabric.

[0006] To update or otherwise change topologies or other features (e.g., to incorporate more efficient network operations, to provide new features, and / or to adapt to changing business network requirements), a network administrator can perform a complex process of updating the underlying controllers and API servers, which can be prone to user error, while also requiring significant development, which can delay implementation of changes, or in some cases, require compromises in data model validation. SUMMARY

[0007] Generally described, the present disclosure describes techniques for a runtime-extensible application programming interface (API) server that can facilitate runtime extension of new topologies and / or features, while also facilitating extensible definition of semantic validation for the new topologies and / or features. Rather than requiring extensive development of controllers to support new topologies and / or features (which can be denoted as "topology / features"), while also developing API servers to accommodate new semantic validation, various aspects of the techniques of the present disclosure can implement a modular architecture in which the API server is decoupled from the topology / features by providing an interface to specify a new data model representing the new topology / features, as well as providing a semantic validation interface to define new semantic validation rules with respect to the new data model. Thus, only the controllers need to be developed to provide the new data model, and register such data model with the API server, before deploying the new topology / features in a data center fabric.

[0008] Further, a monolithic controller for a given topology / feature can be decomposed into sub-controllers that handle discrete aspects of the given topology / feature to facilitate reusability across topology deployments, data center customers, etc. That is, as an example, a monolithic controller for a particular customer that requires a 3-stage Clos using a border gateway protocol (BGP) can be split into two or more controllers (e.g., one for the 3-stage Clos and another for the BGP), such that each individual controller can be quickly retooled and deployed between customers that require a 3-stage Clos and / or BGP (but with different BGP options and / or configurations). Since the API server is decoupled from the topology / features, and largely serves as a validation and monitoring function in the large network controller, the API server can interface with each individual controller to alert the individual controllers of changes with respect to the data models registered to the controllers.

[0009] In this way, various aspects of this technology can facilitate more granular controllers with underlying API servers that are scalable at runtime because they provide a set of interfaces through which new data models (representing topology / features) can be introduced without requiring extensive development of topology / feature-specific API servers. This interface provided by the API server can also define semantic validation rules at runtime to facilitate the semantic validation of new data models. Due to the more granular controller, controller development and subsequent redeployment can be much faster compared to a monolithic controller / API server architecture, potentially reducing controller development time to weeks instead of months (or even more than a year). This increased development speed enables topology / feature expansion, facilitating more efficient network operation of network controllers and data center architectures (as new topologies / features often lead to more efficient data center operations), and also facilitating the semantic validation of business intent to ensure the correct configuration and operation of the data center architecture to support business intent.

[0010] In one example, aspects of this technology are directed to a method comprising: an application programming interface (API) server executed by a processor to access one or more data models stored in a data store; the API server receiving, from a controller, a registration request to register a new data model to the data store, the registration request providing a resource definition specifying semantic validation rules; the API server registering the new data model to the data store; the API server receiving, from a client, a creation request to create a resource for the new data model having initial data conforming to the resource definition; the API server applying semantic validation rules to the initial data to validate the creation request; and the API server creating a resource for the new data model in the data store in response to validating the creation request.

[0011] In another example, aspects of the technology are directed to a device, including: a memory configured to store a data store comprising one or more data models; and one or more processors configured to: execute an application programming interface (API) server to access one or more data models stored in the data store, wherein the API server is configured to: receive from a controller a registration request to register a new data model to the data store, the registration request providing a resource definition specifying semantic validation rules; register the new data model to the data store; receive from a client a creation request to create a resource for the new data model having initial data conforming to the resource definition; apply semantic validation rules to the initial data to validate the creation request; and, in response to validating the creation request, create the resource in the data store for the new data model.

[0012] In another example, the technology relates to a system comprising: a memory configured to store a data store including one or more data models; and one or more processors configured to execute an application programming interface (API) server and a controller, wherein the controller is configured to: send a registration request to the API server to register a new data model to the data store, the registration request providing a resource definition specifying semantic validation rules; wherein the API server is configured to: receive the registration request to register a new data model to the data store; register the new data model to the data store; receive a creation request from a client to create a resource for the new data model having initial data conforming to the resource definition; apply semantic validation rules to the initial data to validate the creation request; and, in response to validating the creation request, create a resource for the new data model in the data store.

[0013] Details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will become apparent from the description, the drawings, and the claims. Attached Figure Description

[0014] Figure 1 This is a block diagram illustrating a network having a data center according to the technology disclosed herein.

[0015] Figure 2 This is a block diagram illustrating an example system of a runtime scalable API server that includes various aspects of the technology described in this disclosure.

[0016] Figures 3A to 3E This is a block diagram illustrating another system that includes various aspects of the technology described in this disclosure, serving as an example runtime scalable API server.

[0017] Figure 4 This is an explanation Figure 2 The flowchart shown illustrates example operations of the system performing various aspects of the semantic verification techniques described in this disclosure.

[0018] Figure 5 This is an explanation Figure 1 Another flowchart illustrating example operations of the API server in performing various aspects of the techniques described in this disclosure. Detailed Implementation

[0019] Figure 1 This is a block diagram illustrating a network having a data center according to the technology of this disclosure. Figure 1In the example method, network 100 includes data center 102 connected to client equipment 120. Data center 102 includes a set of interconnected storage systems and application servers 110A-110N (servers 110). Network protocol (IP) architecture 118 may include a structure provided by one or more layers of physical network devices, such as routers, gateways, switches, hubs, modems, bridges, repeaters, multiplexers, servers, virtual machines running on one or more of the same devices, and other example network devices.

[0020] Generally, data center 102 provides an operating environment for applications and services coupled to customer equipment 120 within the data center, for example, through a service provider network (not shown). Data center 102 may, for example, host infrastructure equipment such as network and storage systems, redundant power supplies, and environmental controls. In some examples, the service provider network coupling customer equipment 120 to data center 102 may be coupled to one or more networks managed by other providers, and thus may constitute part of a large-scale public network infrastructure, such as the Internet.

[0021] In some examples, data center 102 represents one of many geographically distributed network data centers. For example... Figure 1 As illustrated in the example method, data center 102 can be a facility that provides network services to customers via customer equipment 120. Customer equipment 120 can include equipment from entities (such as businesses and governments) and individuals. For example, a network data center can host network services for businesses and end users. Other example services can include data storage, virtual private networks, traffic engineering, file services, data mining, scientific or supercomputing, and so on. In some examples, data center 102 can be a standalone network server, a network peer, or something else. In some examples, data center 102 is a corporate or internal data center.

[0022] In these examples, data center 102 includes a set of storage systems and application servers 110A-110N (servers 110) interconnected via Internet Protocol (IP) architecture 118. IP architecture 118 may include a structure provided by one or more tiers of physical network devices, such as routers, gateways, switches, hubs, modems, bridges, repeaters, multiplexers, servers, virtual machines running on one or more of the same devices, and other example network devices. In the illustrated example, IP architecture 118 includes two layers of nodes: spine nodes 104A and 104B (spine nodes 104) and leaf nodes 108A-108N (leaf nodes 108). Servers 110 provide an execution and storage environment for customer-related applications and data via client devices 120, which may be physical servers, virtual machines, or a combination thereof.

[0023] Although not shown, data center 102 may also include one or more additional switches, routers, hubs, gateways, security devices (such as firewalls, intrusion detection and / or intrusion prevention devices), computer terminals, laptops, printers, databases, wireless mobile devices (such as cellular phones or personal digital assistants), wireless access points, bridges, cable modems, application accelerators, or other network devices.

[0024] exist Figure 1 In the example shown, IP structure 118 includes two layers of nodes: spine nodes 104A and 104B (spine node 104) and leaf nodes 108A-108N (leaf nodes 108). Other topologies can be used in other examples. Server 110 provides an execution and storage environment for customer-related applications and data through client device 120, which can be a physical server, a virtual machine, or a combination thereof.

[0025] Generally, IP architecture 118 represents Layer 2 (L2) and Layer 3 (L3) switching and routing components that provide point-to-point connectivity between servers 110. In one example, IP architecture 118 includes a set of interconnected, high-performance, but off-the-shelf packet-based routers and switches that implement industry-standard protocols. In another example, IP architecture 118 may include off-the-shelf components providing Internet Protocol (IP) point-to-point connectivity. In some multi-tiered networks, such as IP architecture 118, each switch resides in a defined layer of the network. Figure 1 As shown in the example, ridge node 104 resides in the first and top layer 122A, and leaf node 108 resides in the second layer 122B (collectively referred to as "network layer 122"). Figure 1 As shown in the example, each of the ridge nodes 104 is communicatively coupled to each of the leaf nodes 108A-108N.

[0026] In one example approach, IP structure 118 is configured as a multi-level network. Multi-level data center networks, such as Clos or networks with a so-called "fat tree" topology, can be used in data centers to achieve high performance and resilience. In some example approaches, fat tree networks can allow multipathing.

[0027] In one example approach, IP structure 118 includes a Virtual Machine Chassis (VCF). A VCF can be used to provide a low-latency, high-performance architecture that can be managed as a single device. A VCF is built using a spine-and-leaf architecture. In a spine-and-leaf architecture, each spine device is interconnected with one or more leaf devices. A VCF can support up to 20 devices, with a maximum of four devices configured as spine devices.

[0028] In some examples, VCF can be configured to allow path weighting of the end-to-end bandwidth of reflective and reactive paths. This capability is referred to as "smart trunks" in VCF. In some examples, smart trunks can be enabled by a Virtual Chassis Control Protocol (VCCP) running within the VCF to provide globally optimized weights on multipaths.

[0029] In one example approach, IP structure 118 is a loosely federated, multi-level network where all nodes of IP structure 118 run IP routing protocols. Routing protocols may include, for example, the External Border Gateway Protocol (EBGP), encompassing all paths between leaf nodes 108 in IP structure 118, and utilizing Equal Cost Multipath (ECMP) to take advantage of all paths. The Fat Tree Routing (RIFT) protocol allows the use of any set of all available minimum-hop paths, regardless of ECMP constraints. Further information about RIFT can be found in the Internet-Draft entitled RIFT: Routing in Fat Trees (draft-ietf-rift-rift-01), issued by the Internet Engineering Task Force (IETF) on April 26, 2018, and incorporated herein by reference.

[0030] exist Figure 1 In the example, network controller 114 provides a high-level controller for configuring and managing the routing and switching infrastructure of data center 102. Network controller 114 may represent, for example, a software-defined networking (SDN) controller that uses SDN protocols, such as the Path Computing Element (PCE) Communication Protocol (PCEP), to communicate and manage the devices of data center 102. In some examples, network controller 114 may use Extensible Messaging and Presence Protocol (XMPP), PCEP, or Border Gateway Protocol messages to communicate and manage the devices of data center 102. Additionally or alternatively, network controller 114 may use other interface types to communicate with the routing and switching infrastructure of data center 102, such as a Simple Network Management Protocol (SNMP) interface, a Path Computing Element (PCEP) interface, a Device Management Interface (DMI), a CLI, a Routing System Interface (IRS), or any other node configuration interface.

[0031] According to examples of this disclosure, network controller 114 provides a logically—and in some cases physically—centralized controller for facilitating the operation of one or more networks within data center 102. In some examples, network controller 114 may operate in response to configuration input received from network administrator 112. Further information regarding network controller 114 operating alongside other devices in data center 102 can be found in international application PCT / US2013 / 044378, filed June 5, 2013, entitled PHYSICAL PATH DETERMINATION FOR VIRTUAL NETWORK PACKETFLOWS, which is incorporated herein by reference.

[0032] In an example method, such as Figure 1 As shown, network controller 114 communicates with nodes 104 and 108 to configure and manage different topologies and / or features (which may be represented as "topologies / features" or "topology / feature") within IP structure 118. Topology can refer to any topology implementation associated with IP structure 118, such as Level 3 Clos, Level 5 Clos, hypercube, butterfly, fat tree, etc. Features can refer to routing protocols (such as EBGP, BGP, iBGP, intermediate system to intermediate system—IS-IS, Open Shortest Path First—OSPF, etc.), quality of service, multipath, high availability, forwarding mechanisms, or any other feature that supports the topology.

[0033] Generally, network traffic within IP structure 118, such as packet flows between servers 110, can traverse the physical network of IP structure 118 using many different physical paths, depending on specific topology and characteristics. For example, a "packet flow" can be defined by values ​​used in the packet header, such as the network "five-tuple," which specifies the source IP address, destination IP address, source port, and destination port used to route packets through the physical network, along with the communication protocol. The protocol specifies the communication protocol, such as TCP or UDP, and the source and destination ports refer to the source and destination ports of the connection. A group of one or more Packet Data Units (PDUs) conforming to a specific traffic entry represents a flow. Flows can be broadly categorized using any parameters of the PDU, such as source and destination data link (e.g., MAC) and network (e.g., IP) addresses, Virtual LAN (VLAN) tags, transport layer information, Multiprotocol Label Switching (MPLS) or Generic MPLS (GMPLS) tags, and the ingress port of the network device receiving the traffic. For example, a stream can be all PDUs transmitted in a Transmission Control Protocol (TCP) connection, all PDUs generated by a specific MAC address or IP address, all PDUs with the same VLAN tag, or all PDUs received on the same switching port.

[0034] Network controller 114 can configure various topologies within IP structure 118 to effectively route traffic (e.g., avoid congestion and packet dropping, increase the utilization of nodes 104 and 108, provide higher quality of service (QoS), and / or similar). Administrator 112 can initially interface with network controller 114 to configure topologies / features within IP structure 118 to support business intents. That is, administrator 112 can interface with network controller 114 to configure IP structure 118 to adopt specific topologies with different aforementioned identified features for specific customers. Once configured, network controller 114 can make the configuration (implementation topology) of IP structure 118 opaque from the customer's perspective. In other words, the customer may not be aware of the underlying topology of IP structure 118 because there is no need to understand the topology / features of IP structure 118 to support higher-level intents.

[0035] In this regard, intent is a high-level statement defining network service objectives, such as creating a Virtual Private Network (VPN) between site A and site B. Network controller 114 can then translate this intent into low-level configuration data for each of nodes 104 and 108 to support it. Network controller 114 can then interface with nodes 104 and 108 to deploy configuration data implementing the intent in a specific topology of IP architecture 118 with various functionalities. Network controller 114 can perform syntactic and semantic validation on the intent and low-level configuration data to ensure that the configuration data is valid and within the scope of pre-configured service objectives specified by the customer.

[0036] Syntax validation refers to the process of validating configuration data to ensure that it has the appropriate type (e.g., string, integer, array, etc.), size (e.g., bit depth or number of bytes), etc. Semantic validation refers to the process of validating configuration data to ensure that it conforms to certain business objectives. For example, configuration data may include an IP address within an acceptable range, use a specific naming pattern, have a certain format or data arrangement, etc. In other words, syntax validation refers to whether the configuration data conforms to a specific data schema defined for a data model of a given topology / features, while semantic validation refers to whether the content of the configuration data has meaning within the data schema that supports various business objectives (or enterprise objectives, personal objectives, etc.).

[0037] In some architectures, network controller 114 may include devices (virtual and / or physical devices) that work together to perform certain aspects of network controller 114's operations. For example, network controller 114 may include API server 124, which performs syntax validation and, possibly, semantic validation on data stored in data store 125. API server 124 may represent a server that supports synchronous or asynchronous transactions, such as create, read, update, and delete (CRUD) operations performed on a data model that defines how data is stored in data store 125.

[0038] A synchronous API server can support syntax and semantic validation because it fully understands the data model (e.g., the semantic rules programmed to support the business objectives of storing configuration data in data store 125), thus potentially allowing only semantically valid CRUD operations. An asynchronous API server, on the other hand, may provide syntax validation but only offers very generic CRUD operations for a general data model, lacking any semantic validation. The synchronous API server "knows" the data model because the semantic validation rules are defined at compile or startup time, which prohibits adding new data models at runtime, or even changing or adjusting existing data models. An asynchronous API server can add new data models and update existing data models at runtime but cannot support semantic validation. Therefore, API server 124 can represent synchronous API server 124 to provide syntax and semantic validation to ensure that business intent (and the resulting configuration data) conforms to business objectives.

[0039] API server 124 can store configuration data for each node based on a data model defined for a given client topology / characteristics. Network controller 114 can register the data model with API server 124. Specifically, network controller 114 may include one or more controllers 126A-126N (“Controller 126”) that are developed to register data models representing topology / characteristics. API server 124 can translate such data models into an underlying database (e.g., an SQL database) supporting data storage 125. A consistent data model (databases, graph databases, etc.). Once registered, the client (in...) Figure 1 While not explicitly shown in the example, it may include an interface to the network controller 114 provided by the client device 120—for example, a network interface to a portal / graphical user interface (GUI) hosted by the network controller 114—that can interact with the API server 124 to specify intents related to a given data model, which the API server 124 can then pass to a registered controller (e.g., controller 126A) of the controller 126.

[0040] Then, controller 126A can translate the intent into low-level configuration data for a given topology / feature of IP structure 118, where the low-level configuration data is specific to each of nodes 104 and 108 (or a subset of nodes 104 and 108 involved in supporting the underlying topology / features). Controller 126A can interface with API server 124 to write the low-level configuration data to data store 125, where API server 124 can perform syntactic and semantic validation of the low-level configuration data. Assuming the low-level configuration data is successfully validated (syntactically and semantically), API server 124 can write the low-level configuration data to data store 125 according to the underlying data schema (this may include translating the low-level configuration data into data supported by the data schema). API server 124 can interface with controller 126A to indicate successful writing of low-level configuration data to data store 125, at which point controller 126A can interface with IP structure 118 to update nodes 104 and 108 to fulfill the intent.

[0041] However, as mentioned above, in some cases, a synchronous API server may not support runtime extensions of the data model to support new topologies / features while also performing semantic validation. Furthermore, even if new data models can be added at runtime (although semantic validation of such new data models may not be possible), updating the API server at runtime often involves a complex process, including manual intervention, a lack of any formal data modeling language, proprietary code generators (which some administrators may lack experience with and are therefore prone to errors), a lack of binary-coded communication methods, and limited streaming media (e.g., a lack of bidirectional streaming between clients and servers).

[0042] Thus, in order to update or otherwise change the topology or other functions (e.g., to incorporate more efficient network operations, provide new features, and / or adapt to changing business network requirements), the administrator 12 may perform a complex process of updating the underlying controller and API server, which may be prone to user errors and require a lot of development, which may delay the implementation of changes, or in some cases, require compromises in validating business intent.

[0043] According to various aspects of the technology described in this disclosure, API server 124 can facilitate runtime extensions of new data models representing new topologies / features, while also facilitating scalable definitions of semantic validation for new topologies / features. Unlike requiring extensive development of controller 126 to support new topologies and / or functionalities, and simultaneously developing an API server to accommodate new semantic validation, the various aspects of the technology described in this disclosure enable a modular architecture where API server 124 becomes topology / feature-agnostic by providing defined interfaces to specify new data models representing new topologies / features, and providing semantic validation interfaces to define new semantic validation rules relative to the new data models. Therefore, only controller 126 needs to be developed to provide the new data model and register it with API server 124, and then the new topology / features can be deployed within the data center architecture (e.g., IP architecture 118).

[0044] Furthermore, by decoupling controllers 126 from API server 124 through various interfaces supported by API server 124, a monolithic controller for a given topology / feature can be decomposed into sub-controllers that handle discrete aspects of the given topology / feature, facilitating reusability across topology deployments, data center customers, etc. That is, as an example, a monolithic controller for a specific customer requiring Level 3 Closing using Border Gateway Protocol (BGP) can be split into two or more controllers (e.g., one controller for Level 3 Closing and another for BGP), so that each individual controller can be quickly refitted and deployed among customers requiring Level 3 Closing and / or BGP (but with different BGP options and / or configurations). Since API server 124 is topology / feature-agnostic and largely functions as authentication and monitoring within network controller 114, API server 124 can interface with individual controllers 126 to alert them to changes in the data models registered to those controllers 126.

[0045] In operation, API server 124 can access one or more data models stored in data store 125 as described above. API server 124 can wait for controller 126 to connect. Network controller 114 can execute controller 126, which can initialize and then generate a registration request to register a new data model to data store 125. Controller 126 can be developed using a pre-configured data model that defines the data supporting topology / features. This data model can conform to industry standards, proprietary standards, open-source standards, etc., and be specified according to a formal data model language, such as protocol buffer (often called "protobuf"). Controller 126 can register one or more data models through individual registration requests or a single shared registration request.

[0046] In any case, API server 124 can receive a registration request from a controller, such as controller 126A, to register a new data model to data store 125. As described above, API server 124 can present a data model interface to register a new data model (the registration request conforms to the data model) and a semantic validation interface through which semantic validation rules are specified. In some cases, the data model interface includes a semantic validation interface, where the definition of the data model can include definitions of semantic validation rules corresponding to the data specified in the fields to be applied to the data model. In this case, the registration request can provide a resource definition specifying the semantic validation rules for that resource.

[0047] In response to receiving a registration request, API server 124 can register a new data model to data store 125. API server 124 can maintain the association between data models and controllers (which may be referred to as a registry), and can update this registry to instruct controller 126A to associate with the new data model as part of processing the registration request. Furthermore, API server 124 can translate database-independent data models (meaning the data model is not defined for any specific database language) into a language that conforms to the specific database language supporting data store 125. In some cases, data store 125 may include different databases using multiple different database languages, such as SQL, XQuery, Object Query Language (OQL), GraphQL, Language Integrated Query (LINQ), etc.

[0048] After translating the data model into a data schema that conforms to the underlying database language of the database-supported data storage 125, API server 124 stores the data schema in the database-supported data storage 125. API server 124 can also parse semantic validation rules during the translation process and maintain a set of semantic validation rules that determines which resources of the data schema each semantic validation rule applies to. Then, API server 124 can send an acknowledgment to controller 126A indicating that the data model has been stored in data storage 125.

[0049] Then, the client (in) Figure 1 (Also not shown in the example, but can be executed by client device 120), it can continue to interface with network controller 114 (more specifically, API server 124) to generate various requests. For example, the client can generate a creation request to create a resource with initial data conforming to the resource definition specified in the data model for a new data model. In some cases, these requests do not originate directly from the client. Instead, the client interfaces with network controller 114 to define an intent, which instructs one of controllers 126 (e.g., controller 126A) to translate the intent into low-level configuration data. Controller 126A can then generate a request to create a resource for the new data model. Controller 126A can then send the creation request to API server 124.

[0050] API server 124 can receive creation requests from clients (e.g., directly from the client or indirectly from the client via controller 126A) to create resources for new data models with initial data conforming to the resource definition. API server 124 can identify which data model the creation request applies to using a unique controller identifier (UCI) specified in the creation request that identifies controller 126A. API server 124 can use the UCI to perform a lookup in the registry to identify the new data model. In some cases, when controller 126 is able to register multiple data models, the creation request can also specify a data model unique identifier (DMUI). API server 124 can then use the DMUI to distinguish between multiple registered data models.

[0051] After determining the new data model, API server 124 can identify the resource being created from the creation request (e.g., resolve the Resource Identifier (RID)). API server 124 can then identify the semantic validation rules specified for the resource in the resource definition (these semantic validation rules can be associated with and indexed by the RID so that API server 124 can perform a lookup in the semantic validation rule set using the RID to determine the semantic validation rules). API server 124 can apply the semantic validation rules to the initial data to validate the creation request. API server 124 can then respond to the validation of the creation request and create the resource for the new data model in the data store.

[0052] In this way, various aspects of the technology can facilitate a more granular controller 126 with an underlying API server 124 that is scalable at runtime, because a set of interfaces is provided through which new data models (representing topology / features) can be introduced without requiring extensive development of a topology / feature-specific API server 124. This interface provided by the API server 124 can also enable the definition of semantic validation rules at runtime to facilitate the semantic validation of new data models. Due to the more granular nature of the controller 126, the development and subsequent redeployment of the controller 126 can occur much faster compared to a monolithic controller / API server architecture, potentially reducing the development time of the controller 126 to weeks instead of months (or even more than a year). This increased development speed enables the expansion of topology / features, facilitating more efficient network operation of the controller 114 and data center structure 118 (because new topology / features typically lead to more efficient operation of data center 102), while also facilitating the semantic validation of business intents to ensure the correct configuration and operation of data center structure 118 to support those intents.

[0053] Although described in the context of a specific scenario, namely data center 102 in this example, various aspects of these technologies are generally applicable to any API server that supports dynamically defined data models. That is, any API server requiring dynamic, runtime scalability, and semantic validation can employ these technologies to facilitate the rapid deployment of controllers that interface with the API server to manage data models while preserving semantic validation. Therefore, these aspects of the technology should not be limited to network environments involving data centers, IP infrastructures, or even network controllers, but can be deployed for any API server in any computer network environment. Consequently, the remaining examples provided below focus on the interaction between the API server and the controller to illustrate, in a general sense, the interface provided by the API server that allows runtime scalability and semantic validation without requiring restarts, reinstallations, or other disruptive processes.

[0054] Figure 2This is a block diagram illustrating an example system that includes various aspects of a runtime scalable API server operating according to the techniques described in this disclosure. Figure 2 In the example, system 200 includes an API server 224, a data storage 225, a controller 226, and a client 228. API server 224 may represent an example of API server 124, and data storage 225 may represent an example of data storage 125. Controller 226 may represent an example of controller 126. Client 228 may represent a client described above that is executed by client device 120.

[0055] In some cases, a single computing device, such as a blade server, workstation, desktop computer, laptop computer, network controller, etc., can act as API server 224 and controller 226. In other cases, a virtual computing device, including one or more computing devices that support the execution of virtual computing devices, can act as API server 224 and controller 226. In these cases, logical (or in other words, virtual) computing devices can execute different parts of system 200, which appear as a single physical computing device.

[0056] In any case, API server 224 can execute API service 230 and monitoring service 232. API service 230 can provide an interface through which data models are registered and semantic validation rules are defined. API service 230 can manage operations performed relative to resources defined by the data model, such as the create, read, update, and delete (CRUD) operations mentioned above. API service 230 can present a RESTful API (REST API) that adheres to a set of architectural constraints, such as a client-server architecture consisting of clients, servers, and resources, with requests managed via Hypertext Transfer Protocol (HTTP) and stateless client-server communication (meaning no client information is stored between requests, and each request is independent and unrelated). Furthermore, REST APIs may require buffered data to simplify client-server interaction and a unified interface between components so that information is transmitted in a standard format (e.g., protocol buffers, which may be called "protobufs" or "protos"). REST APIs may also require a hierarchical system that organizes each type of server involved in retrieving request information into a layer transparent to the client, such as to client 228.

[0057] API service 224 can also implement a remote procedure call framework, represented as gRPC, which allows client 228 to directly invoke methods on API service 230, which executes on separate, different computing devices, as if API service 230 were executing on the local machine of client 228. API service 224 can therefore support REST APIs via HTTP and gRPC, providing a hybrid server that enables interaction between controller 226 and API server 224 via gRPC over HTTP version 2 (HTTP2), and interaction between clients 228 via gRPC and HTTP supporting REST APIs.

[0058] Monitoring service 232 can represent and monitor the data model stored in data store 225 on behalf of a registered controller. Monitoring service 232 can establish streams for the registered controller via HTTP / 2, allowing it to push events indicating changes to the data model associated with the registered controller. Monitoring service 232 enables the registered controller to monitor and act on such events in near real-time, allowing the controller to adapt to changes in resources defined according to the relevant data model. Figure 1 In the example, controller 126A can recognize changes to the BGP peer, for example, by monitoring events provided by service 232, and generate configuration data to reconfigure IP structure 118 to improve the operation of IP structure 118 due to changes in the BGP peer. API service 230 can initially wait for a controller, such as controller 226, to connect to API server 224 and register the new data model.

[0059] Controller 226, such as Figure 2 As shown in the example, it can include a gRPC / HTTP unit 240 and a protocol buffer 241 that defines the data model. Protocol buffer 241 refers to an open-source framework through which structured data is serialized, and parameters are defined and returned in the form of a callable method (gRPC). More information about gRPC and protocol buffers can be found in the online article entitled “Implementing Remote Procedure Calls with gRPC and Protocol Buffers”, available at scotch.io / tutorials / implementing-remote-procedure-calls-with-grpc-and-protocol-buffers, last accessed on August 25, 2021, the entire content of which is incorporated herein by reference.

[0060] Controller 226 can connect to API server 224, which in turn calls API service 230. Controller 226 can initiate a gRPC message via HTTP / 2 to request the registration of protocol buffer 241 in data store 225. This gRPC message can represent an example of the registration request described above, while protocol buffer 241 can represent a new data model (along with semantic validation rules) to be registered with data store 225. Controller 226 can then send the registration request (displayed as registration request 261) to API service 230.

[0061] API service 230 can receive registration request 261 to register a new data model defined by protocol buffer 241, wherein protocol buffer 241 can again provide a resource definition specifying semantic validation rules. This resource definition can define one or more resources according to one or more of a unique identifier, resource type, resource name, API group, version, specification, and status, wherein the specification can include semantic validation rules.

[0062] API service 230 can parse protocol buffer 241 to identify resource definitions and generate a data schema consistent with the underlying database language supporting data storage 225 for storing the data model within the underlying database. API service 230 can also update protocol buffer registry 231, which can be the aforementioned... Figure 1 The example registry is shown in the example to associate controller 226 with protocol buffer 241 and specify semantic validation rules related to resources (or various semantic validation rules related to various resources defined by the data model). API service 230 can generate gRPC response message 263 to confirm successful registration of the data model with data storage 225 and send the gRPC response message to controller 226.

[0063] In response to receiving gRPC response message 263, controller 226 may invoke gRPC / HTTP2 240 to generate a monitoring registration gRPC message 265, requesting API server 224 to register controller 226 for event stream monitoring of the new data model represented by protocol buffer 241 and stored in data storage 225. Controller 226 may send the monitoring registration gRPC message 263 to API server 224.

[0064] API server 224 receives monitoring registration gRPC message 263 and, in response, invokes monitoring service 232. This service can process the monitoring registration gRPC message 263 to add controller 226 to the monitoring registry 233. The monitoring registry 233 can store the association between controller 226 and the new data model stored in data storage 225. Monitoring service 232 can establish the aforementioned event monitoring stream (where events can be specified as protocol buffers and transmitted via HTTP / 2), subsequently monitoring data storage 225 to identify any changes to the new data model stored in data storage 225.

[0065] Changes to the data model can include operations such as creating new resources based on the data model, reading resources stored based on the data model, updating resources stored based on the data model, and deleting resources stored based on the data model. In response to such a change to the data model, monitoring service 232 can generate a protocol buffer representing the event and send the protocol buffer to controller 226 via HTTP / 2. This event stream is displayed as event stream 267, where the first event sent via event stream 267 can include a confirmation event that controller 226 has successfully registered with monitoring registry 233.

[0066] Client 228 may include a gRPC / HTTP unit 250, which can operate similarly to gRPC / HTTP2 unit 240, except that gRPC / HTTP can implement HTTP version 1 instead of HTTP version 2 (HTTP2). In any case, client 228 may present an interface through which the client's administrator can input business intent to perform some business objectives, which may result in CRUD operations 281 being generated and sent to API service 224 via HTTP.

[0067] API server 224 can receive CRUD operation 281, which may include a creation request for creating a resource with initial data conforming to the resource definition for a new data model. In response to receiving CRUD operation 281, API server 224 can invoke API service 230, which processes CRUD operation 281, including the aforementioned creation request. As an example, API service 230 can process the creation request by applying semantic validation rules to the initial data to validate the creation request. In some cases, API service 230 may also apply syntax validation rules to the initial data to complete the validation of the creation request. API service 230 can then create the resource of the new data model in data store 225 in response to the validation of the creation request. API service 230 can generate and send a gRPC response message 283 to client 228, indicating that the resource has been created in the data model stored in data store 225.

[0068] While monitoring data storage 225, monitoring service 232 can determine that the resource was created for a data model stored in data storage 225. Monitoring service 232 can access monitoring registry 233 to determine if the modified data model is associated with (or, in other words, owned by) controller 226, and generate an event protocol buffer specifying that the resource was created for the new data model stored in data storage 225. Monitoring service 232 can send the event protocol buffer to controller 226 via event stream 267. Controller 226 can process even numbers of protocol buffers and translate the event protocol buffers according to programmed business logic.

[0069] Figures 3A to 3E This is a block diagram illustrating another system that includes various aspects of the operation of an example runtime scalable API server based on the techniques described in this disclosure. First refer to... Figure 3A For example, system 300A includes API server 324, which may represent an example of API server 224 and / or 124. API server 324 includes API service 330 and monitoring service 332, wherein API service 330 may be similar to API service 230 if not substantially similar, and monitoring service 332 may be similar to monitoring service 232 if not substantially similar. API service 330, like API service 230, maintains protocol buffer registry 331, while monitoring service 332, like monitoring service 232, maintains monitoring registry 333. Figure 3A In the example, API server 324 initially knows nothing about any data model or resource (meaning there is no protocol buffer registered in protocol buffer registry 331 and no controller registered in monitoring registry 333).

[0070] Next reference Figure 3BFor example, system 300A transitions to system 300B, where controller 326A establishes a connection with API server 324. Controller 326A has a designated name of "1" (which could be another way of referring to a unique identifier) ​​and owns protocol buffers "A" and "B". Therefore, controllers typically have a 1:n (1:n) data model ratio, where any controller can "own" multiple different data models. Controller 326A can register data models A and B with API server 324, where API service 330 updates protocol buffer registry 331 to specify messages A{} and B{} representing data models A and B, as well as all data models that depend on data models A and B (i.e., Aa and Bb in this example, which are represented as messages Aa{} and Bb{}).

[0071] Next reference Figure 3C For example, in the transition from system 300B to system 300C, after successfully registering protocol buffers A and B, controller 326A interfaces with API server 324 to register event monitoring for protocol buffers A and B. In other words, controller 326A subscribes to events through monitoring service 332 of API server 324. Monitoring service 332 updates monitoring registry 333 to indicate that controller 326A (with "name 1") has registered for event monitoring of resources A and B. Monitoring service 332 can open an event stream and notify controller 326A of any changes to resources A and B.

[0072] Next reference Figure 3D For example, system 300C transitions to system 300D, where another controller 326B with the name "2" owns protocol buffers "C" and "D". Controller 326B can access API server 324 by calling gRPC API to API service 330 to register protocol buffers C and D, which API service 330 can register as messages C{} and D{} to protocol buffer registry 331.

[0073] Next reference Figure 3E For example, in the transition from system 300D to system 300E, controller 326B interfaces with monitoring service 332 to register controller 326B with API server 324. Monitoring service 332 can update monitoring registry 333 to register controller 326B in the list of registered controllers with "Name: 2". Monitoring service 332 can also establish an event stream with controller 326B, thereafter notifying controller 326B of any changes to resources C and D.

[0074] As mentioned above, the data model (including resources) is defined as a protocol buffer, which is a language-neutral, platform-neutral, and extensible serialized structured data. Each resource definition can follow the format below, where the resource itself has a unique identifier (uid, also known as a RID), type, name, API group to which the resource belongs, and version. In addition, a resource may have a canonical field containing the resource's specification (also known as a "spec field"), as well as a state field that maintains the resource's state. This resource is defined as a message (this is the primary resource definition supported by the protocol buffer). An example of a resource definition is provided below.

[0075]

[0076] The resource definitions described above are registered by controller 326A (as an example) with API server 324, and can then be created, read, updated, and deleted using a common API applicable to all resources. Below is an example of a resource definition display.

[0077]

[0078] This data structure is sent to a general API server, such as API server 324:

[0079]

[0080] Figure 4 This is an explanation Figure 2 The illustrated flowchart shows an example operation of the system performing various aspects of the semantic verification techniques described in this disclosure. Initially, client 228 may invoke gRPC / HTTP250 (representing gRPC API) to create resources (which may be in the form of protocol buffers and server stubs, where the server stub is a wrapper layer around the calling layer and can be dynamically generated during protocol buffer formation), ensuring grammatical correctness (where client 228 may perform syntax verification) (400).

[0081] API server 224 can receive gRPC requests (in...) Figure 2 The example shows a gRPC request 281)(402) that calls API service 230, which uses protocol buffer reflect (a method that allows dynamic manipulation of messages based on protocol buffers / message descriptors) to resolve the resource protocol buffer (404).

[0082] API service 230 can then extract the protocol buffer field options and run / apply the built-in semantic validator (406, 408). That is, API service 230 can apply the built-in semantic validator (which refers to another way of defining semantic validation rules) to the extracted field options and the underlying data specified for the resource. When validation fails (meaning the data specified for the resource does not meet the semantic validation rule conditions), API service 230 can generate and send a gRPC response message indicating validation failure ("No" 410, 412). When validation succeeds (meaning the data specified for the resource meets the semantic validation rule conditions), API service 230 can apply the schema determined for the data model to the resource and store the resource in data storage 225 ("Yes" 410, 414). API service 230 can then generate and send a gRPC response indicating the resource has been successfully stored in data storage 225 (416).

[0083] In this regard, the resource definition will ensure that the input data is syntactically correct and only allows the defined data types. Furthermore, to perform semantic validation on the data before it is persisted to the data store 225, the API server 224 can provide general semantic validation functionality that can be applied to any resource, where the fields to be semantically validated are commented in the resource definition.

[0084] Below is an example of such a comment in a resource definition.

[0085]

[0086] The following is an example of an implementation of the minimum / maximum range validator.

[0087]

[0088] Figure 5 This is an explanation Figure 1Another flowchart illustrates the example operations of the API server performing various aspects of the techniques described in this disclosure. Initially, network controller 114 may execute API server 124, through which it accesses one or more data models (500) stored in data store 125. API server 124 may then wait for a connection from controller 126. Network controller 114 may execute controller 126, which may initialize and then generate a registration request to register a new data model to data store 125. Controller 126 may be developed using a pre-configured data model that defines the data supporting the topology / features. This data model may conform to industry standards, proprietary standards, open-source standards, etc., and be specified according to a formal data model language, such as the protocol buffer (often referred to as "protobuf") described above. Controller 126 may register one or more data models through individual registration requests or a single shared registration request.

[0089] In any case, API server 124 may receive a registration request from a controller, such as controller 126A, to register a new data model to data store 125, wherein the definition of the data model may include the definition of corresponding semantic validation rules to be applied to the data specified in the fields of the data model (502). In response to receiving the registration request, API server 124 may register the new data model to data store 125 (504). API server 124 may maintain the association between the data model and the controller (which may be called a registry), and API server 124 may update the registry to instruct controller 126A to associate with the new data model as part of processing the registration request. In addition, API server 124 may translate database-agnostic data models (meaning that the data model is not defined for any particular database language) into a language that conforms to the specific database language supporting data store 125. In some cases, data store 125 may include different databases using multiple different database languages, such as SQL, XQuery, Object Query Language (OQL), GraphQL, Language Integrated Query (LINQ), etc.

[0090] After translating the data model into a data schema that conforms to the underlying database language of the database-supported data storage 125, API server 124 stores the data schema in the database-supported data storage 125. API server 124 can also parse semantic validation rules during the translation process, maintain a set of semantic validation rules, and determine which resources of the data schema each semantic validation rule applies to. Then, API server 124 can send an acknowledgment to controller 126A indicating that the data model has been stored in data storage 125.

[0091] Then, the client (in) Figure 1(Not shown again in the example, but which can be executed by client device 120), it can continue to interface with network controller 114 (more specifically, API server 124) to generate various requests. For example, the client can generate a creation request to create a resource with initial data conforming to the resource definition specified in the data model for a new data model. In some cases, these requests do not come directly from the client. Instead, the client interfaces with network controller 114 to define an intent, invoking one of controllers 126 (e.g., controller 126A) to translate the intent into low-level configuration data. Controller 126A can then generate a request to create a resource for the new data model. Controller 126A can then send the creation request to API server 124.

[0092] API server 124 may receive a creation request from a client (e.g., directly from the client or indirectly from the client via controller 126A) to create a resource (506) for a new data model with initial data conforming to the resource definition. API server 124 can identify which data model the creation request applies to by using a unique controller identifier (UCI) specified in the creation request that identifies controller 126A. API server 124 can use the UCI to perform a lookup in the registry to identify the new data model. In some cases, when controller 126 is able to register multiple data models, the creation request may also specify a data model unique identifier (DMUI). API server 124 can then use the DMUI to distinguish between the multiple registered data models.

[0093] After identifying the new data model, API server 124 can determine the resource being created from the creation request (e.g., resolving the resource identifier - RID). API server 124 can then identify the semantic validation rules specified for the resource in the resource definition (the semantic validation rules can be associated with and indexed by the RID so that API server 124 can perform a lookup in the semantic validation rule set using the RID to identify the semantic validation rules). API server 124 can apply the semantic validation rules to the initial data to validate the creation request (508). API server 124 can then respond to the validation of the creation request by creating the resource for the new data model in data storage 125 (510).

[0094] In this way, various aspects of this technology can be implemented in the following examples.

[0095] Example 1. A method comprising: executing an application programming interface (API) server by a processor, accessing one or more data models stored in a data store via the API server; receiving, via the API server and from a controller, a registration request to register a new data model to the data store, the registration request providing a resource definition specifying semantic validation rules; registering the new data model to the data store via the API server; receiving, via the API server and from a client, a creation request to create a resource for the new data model having initial data conforming to the resource definition; applying semantic validation rules to the initial data via the API server to validate the creation request; and creating a resource for the new data model in the data store via the API server and in response to validating the creation request.

[0096] Example 2. According to the method described in Example 1, registering a new data model includes registering the new data model without restarting the API server and data storage.

[0097] Example 3. The method according to any combination of Examples 1 and 2, wherein the request to register a new data model includes a protocol buffer specifying the new data model and semantic validation rules.

[0098] Example 4. The method according to any combination of Examples 1 to 3, wherein receiving a registration request includes receiving a registration request to register a new data model as a remote procedure call (RPC) to a data store.

[0099] Example 5. The method described according to any combination of Examples 1 to 4, wherein the resource definition includes a unique identifier, resource type, resource name, API group, version, specification, and status.

[0100] Example 6. The method described in Example 5, wherein the specification includes semantic validation rules.

[0101] Example 7. The method described according to any combination of Examples 1 to 6, wherein the semantic verification rule invokes verification functionality supported by the API server.

[0102] Example 8. The method according to any combination of Examples 1 to 7, wherein applying semantic validation rules includes applying semantic validation rules other than syntax validation rules to the initial data in order to validate the creation request.

[0103] Example 9. The method according to any combination of Examples 1 to 8 further includes receiving one or more of the following via an API server and from a client: a read request to read a resource, an update request to update the initial data of a resource, and a delete request to delete a resource.

[0104] Example 10. The method according to any combination of Examples 1 to 9, wherein the controller includes a first controller, wherein the network controller includes an API server and a plurality of controllers, wherein the plurality of controllers includes the first controller, wherein each of the plurality of controllers defines a data model for configuring one or more aspects of the underlying network topology, and wherein the network controller provides one or more services to support the configuration and management of the network structure.

[0105] Example 11. An apparatus comprising: a memory configured to store a data store including one or more data models; and one or more processors configured to: execute an application programming interface (API) server to access one or more data models stored in the data store, wherein the API server is configured to: receive from a controller a registration request to register a new data model to the data store, the registration request providing a resource definition specifying semantic validation rules; register the new data model to the data store; receive from a client a creation request to create a resource for the new data model having initial data conforming to the resource definition; apply semantic validation rules to the initial data to validate the creation request; and, in response to validating the creation request, create a resource in the data store for the new data model.

[0106] Example 12. The device according to Example 11, wherein when the API server is configured to register a new data model, it is configured to register the new data model without restarting the API server and the data storage.

[0107] Example 13. The device according to any combination of Examples 11 and 12, wherein the request to register a new data model includes a protocol buffer specifying the new data model and semantic verification rules.

[0108] Example 14. The device according to any combination of Examples 11 to 13, wherein receiving a registration request includes receiving a registration request to register a new data model as a remote procedure call (RPC) to a data store.

[0109] Example 15. A device according to any combination of Examples 11 to 14, wherein the resource definition includes a unique identifier, resource type, resource name, API group, version, specification, and status.

[0110] Example 16. The device according to Example 15, wherein the specification includes semantic verification rules.

[0111] Example 17. The device according to any combination of Examples 11 to 16, wherein the semantic verification rule invokes a verification function supported by an API server.

[0112] Example 18. The device according to any combination of Examples 11 to 17, wherein when the API server is configured to apply semantic validation rules, it is configured to apply semantic validation rules other than syntax validation rules to the initial data in order to validate the creation request.

[0113] Example 19. The device according to any combination of Examples 11 to 18, wherein the API server is further configured to receive one or more of the following from the client: a read request to read a resource, an update request to update the initial data of the resource, and a delete request to delete a resource.

[0114] Example 20. A system comprising: a memory configured to store a data store including one or more data models; and one or more processors configured to execute an application programming interface (API) server and a controller; wherein the controller is configured to: send a registration request to the API server to register a new data model to the data store, the registration request providing a resource definition specifying semantic validation rules; wherein the API server is configured to: receive the registration request to register a new data model to the data store; register the new data model to the data store; receive a creation request from a client to create a resource for the new data model having initial data conforming to the resource definition; apply semantic validation rules to the initial data to validate the creation request; and, in response to validating the creation request, create a resource for the new data model in the data store.

[0115] The techniques described in this statement can be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, aspects of the techniques can be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, and any combination of such components. The terms "processor" or "processing circuitry" generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. Control units composed of hardware can also execute one or more of the techniques described in this disclosure.

[0116] Such hardware, software, and firmware can be implemented within the same device or in separate devices to support the various operations and functions described in this disclosure. Furthermore, any unit, module, or component described can be implemented together or separately as a discrete but interoperable logical device. Describing different features as modules or units is to highlight different functional aspects and does not necessarily mean that these modules or units must be implemented by separate hardware or software components. Rather, the functionality associated with one or more modules or units can be performed by separate hardware or software components, or integrated into common or separate hardware or software components.

[0117] The techniques described in this disclosure can also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, which contains instructions. Instructions embedded or encoded in a computer-readable medium can cause a programmable processor or other processor to perform the method, for example, when the instructions are executed. Computer-readable media can include non-transitory computer-readable storage media and transient communication media. Tangible and non-transitory computer-readable storage media can include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), flash memory, hard disk, CD-ROM, floppy disk, cartridge, magnetic media, optical media, or other computer-readable storage media. The term "computer-readable storage medium" refers to a physical storage medium, and not a signal, carrier, or other transient medium.

[0118] Various examples have been described. These and other examples are all within the scope of the claims.

Claims

1. A method for an application programming interface server, comprising: executing, by a processor, an application programming interface (API) server through which one or more data models stored into a data store are accessed; receiving, by the API server and from a controller, a registration request to register a new data model into the data store, the registration request providing a resource definition specifying semantic validation rules; registering, by the API server, the new data model into the data store; receiving, by the API server and from a client, a create request to create a resource for the new data model with initial data conforming to the resource definition; applying, by the API server, the semantic validation rules to the initial data in order to validate the create request; and creating, by the API server and in response to validating the create request, the resource for the new data model in the data store. Registering the new data model includes registering the new data model without restarting the API server and the data store.

2. The method of claim 1, wherein, The request to register the new data model includes a protocol buffer specifying the new data model and the semantic validation rules.

3. The method of claim 1, wherein, Receiving the registration request includes receiving a registration request to register the new data model into the data store as a remote procedure call (RPC).

4. The method of claim 1, wherein, The resource definition includes a unique identifier, a resource type, a resource name, an API group, a version, a schema, and a state.

5. The method of claim 1, wherein, The schema includes the semantic validation rules.

6. The method of claim 5, wherein, The semantic validation rules invoke validation functions supported by the API server.

7. The method of claim 1, wherein, Applying the semantic validation rules includes applying the semantic validation rules in addition to syntax validation rules to the initial data in order to validate the create request.

8. The method of claim 1, wherein, 9. The method of claim 1, further comprising receiving, by the API server and from the client, one or more of a read request to read the resource, an update request to update initial data of the resource, and a delete request to delete the resource.

10. The method of claim 1, the controller includes a first controller, wherein wherein a network controller includes the API server and a plurality of controllers, wherein the plurality of controllers includes the first controller, wherein each of the plurality of controllers defines a data model for configuring one or more aspects of an underlying network topology, and wherein the network controller provides one or more services to support configuration and management of a network fabric.

11. An apparatus for an application programming interface server, comprising: a memory configured to store a data store including one or more data models; and one or more processors configured to: execute an application programming interface (API) server through which the one or more data models stored into the data store are accessed, wherein the API server is configured to: ​ receiving, from a controller, a registration request to register a new data model in the data store, the registration request providing a resource definition specifying a semantic validation rule; registering the new data model in the data store; receiving, from a client, a create request to create a resource for the new data model having initial data conforming to the resource definition; applying the semantic validation rule to the initial data to validate the create request; and in response to validating the create request, creating the resource for the new data model in the data store.

12. The apparatus of claim 11, wherein, the API server, when configured to register the new data model, is configured to register the new data model without restarting the API server and the data store.

13. The apparatus of claim 11, wherein, the request to register the new data model includes a protocol buffer specifying the new data model and the semantic validation rule.

14. The apparatus of claim 11, wherein, receiving the registration request includes receiving a registration request to register the new data model in the data store as a remote procedure call, RPC.

15. The apparatus of claim 11, wherein, the resource definition includes a unique identifier, a resource type, a resource name, an API group, a version, a specification, and a state.

16. The apparatus of claim 15, wherein, the specification includes the semantic validation rule.

17. The apparatus of claim 11, wherein, the semantic validation rule invokes a validation function supported by the API server.

18. The apparatus of claim 11, wherein, the API server, when configured to apply the semantic validation rule, is configured to apply the semantic validation rule, in addition to a syntax validation rule, to the initial data to validate the create request.

19. The apparatus of claim 11, wherein, the API server is further configured to receive, from the client, one or more of a read request to read the resource, an update request to update the initial data of the resource, and a delete request to delete the resource.

20. A system for an application programming interface server, comprising: a memory configured to store a data store including one or more data models; and one or more processors configured to execute an application programming interface, API, server and a controller; wherein the controller is configured to: send, to the API server, a registration request to register a new data model in the data store, the registration request providing a resource definition specifying a semantic validation rule; wherein the API server is configured to: receive the registration request to register the new data model in the data store; register the new data model in the data store; receive, from a client, a create request to create a resource for the new data model having initial data conforming to the resource definition; apply the semantic validation rule to the initial data to validate the create request; and in response to validating the create request, create the resource for the new data model in the data store.

Images