Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to understand the design of API rapid development platform". In daily operation, I believe many people have doubts about how to understand the design of API rapid development platform. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "how to understand the design of API rapid development platform". Next, please follow the editor to study!

When I talked about the API gateway in the headline, I once talked about the rapid development platform, that is, putting some content of the rapid development of API into the API gateway. In fact, it revolves around the API lifecycle management, including the development state, the operation state, and the operation and maintenance state.

For API gateway, it is more to solve the problem of running state. API gateway itself should lighten the design and do not do too much work such as protocol conversion, adaptation, data mapping and so on. These work should be completed on the API development platform. The ultimate goal of the API development platform is to develop and expose a standard Http API interface, and register and access the interface to the API gateway.

API Lifecycle Management

From the perspective of API lifecycle management, the entire subsystem is divided as follows:

To put it simply, this part can be divided into four subsystems, namely, API development platform, API gateway engine, API monitoring operation and maintenance platform, API lifecycle management and control platform.

The adapters and protocol conversion in the traditional ESB bus can be transferred to the API rapid development platform, that is, the API development platform exposes the standard API service interface, registers and accesses the API gateway engine. For the API monitoring platform, log information is collected from the engine for API performance monitoring and log monitoring analysis.

API lifecycle management platform implements API interface from design, development, testing, deployment to online lifecycle management. It can also be understood as a unified management portal of the underlying three subsystems, which is integrated with the following three subsystems.

The micro-service API interface developed and configured by the API development platform can be automatically deployed to the micro-service running platform.

Object-based modeling driver

In the implementation of the whole API development platform, the core idea should still be based on object modeling-driven, through object modeling to achieve a good interface and underlying database, database table decoupling, but also convenient to achieve the underlying multi-database, multi-table support ability.

At present, many API rapid development platforms are based on database objects or tables, and directly publish API interface services similar to CRUD, but based on the direct release of database tables, we still recommend reverse object layer to facilitate subsequent operations such as related composition and rule extension in the object layer.

Object Modeling and API Interface contract

Objects can be created directly in the API development platform and data items can be defined. The object is a multi-tier tree entity. An object can generate multiple tables to the database. For existing data objects, you can also combine multiple data objects into a composite object structure.

The advantage of an object is that a complete object belongs to the same life cycle and can be controlled by transactions together.

A designed object can generate standard interface operation methods such as POST,GET,DELETE by default. Similar to the figure below, the entire object interface contract should be generated automatically.

Defined objects can directly generate interface contract files such as RAML,YAML,WADL.

Like the Swagger tool, the completed object modeling itself can also directly export the client consumption framework under different languages and different development frameworks, and the server provides the framework code.

Object adapts to the database

As mentioned earlier, it can either reverse the object directly in the database, or adapt the object to the database after the object modeling is complete. Complete the mapping between objects and database tables. An object can be mapped to multiple database tables, so in the mapping process, in addition to the mapping of database tables and fields, it is also necessary to complete the mapping operation of primary and foreign key association relations.

After mapping and adapting between the object model and database tables, the basic published API interface is available.

API interface release

For the completed object definition, you can choose which specific API interface service capabilities to publish. For example, you can select only the publishing query interface, or you can only select the POST interface for publishing data import, and so on.

Pay attention to the publication of the API API, which can be based on global object modeling and configure the data item information that needs to be published to the interface. In many cases, our operation on data objects is not to manipulate the whole set of objects, but only part of the data items.

API Interface Simulation Test and Verification

The published API interface can be simulated and verified, so it is necessary to provide online API testing tools, which can facilitate the online testing of API interface. At the same time, the tested use cases and test data can be saved.

API interface document generation

Support the ability to automatically generate API interface documents. This place can be directly docked with tools such as open source Swagger to achieve the automatic generation of API interface documents.

Object common interface operation

When the object definition is completed, the relevant API interfaces can be generated automatically based on the object. Here is a simple list of common object-based interface methods, including adding a piece of data, updating, querying, and deleting data based on the primary key. The other is to query the data based on conditional query and so on.

Open source another xmysql tool in GtiHub, you can directly publish the database tables in the entire mysql database to the RestAPI interface, you can install and try it.

Npm install-g xmysql xmysql-h localhost-u mysqlUsername-p mysqlPassword-d databaseName http://localhost:3000

Note that Node.js needs to be installed in advance. The list of some API methods is as follows:

Since none of the generated API interfaces has relevant permission control, the open source tool is only used for its own testing and verification. However, the generated method and API can be used as a reference for API development tools.

In fact, for the generation of API interface, we do not recommend that all queries under complex query conditions are realized through the GET method. A better idea is to use the POST method to deal with the query conditions as POST input.

One-time generation of composite objects

For example, taking the order as an object actually includes the order header and the order schedule, while the API generation can generate the insert operation and query operation based on the order object at one time. The final query is an order composite entity Json data. For order insertion, the whole order entity information is prepared first, and the data insertion is completed by calling the API interface at once, which is also convenient for transaction control when the API interface is implemented.

The API interface generated by the composite object is more similar to the API interface service capabilities exposed by the domain object.

Paging support

For the generation of query API API service, the paging ability should be supported. The specific page size and the number of pages accessed by this query can be set as the query input parameters of the API API.

Define the API interface directly and publish it

Earlier, we talked about publishing API interface services based on objects, but there are still some business rule logic class interfaces and complex management data query class interfaces that can not be generated automatically through objects.

Therefore, you also need to be able to implement method-based publishing of API interface services.

That is, the API rapid development platform can customize the API interface and define the input parameters and output parameter information of the API interface in detail. At the same time, the binding of the defined interface implementation and the background method.

Implement the binding to the API interface in the JAR package

You can bind a method or function in a JAR package and publish a method or function as a Http API interface method. This implementation can be seen in many current cloud service bus products of public clouds.

Binding between implementation and dynamic SQL

You can bind a defined API interface method to a dynamic SQL. Among them, the dynamic SQL itself has specific dynamic input parameters, and these input parameters are mapped to the input in the definition of API interface. At the same time, the output result of the SQL statement query is mapped to the output field defined by the API interface.

If dynamic SQL is an insert or update class, you can also perform data mapping and binding operations through parameterized variables.

Bind to a stored procedure

The stored procedure of a database is actually a method function, so the input and output defined by the API interface can be mapped and bound with the input and output of the database stored procedure.

It is important to note that there are differences in schema information acquisition and adaptation for different database stored procedures, which is why a separate unified database adaptation layer is built in the figure above.

Rule processing

During the development of the API interface, you can do some simple rule processing. The details are as follows:

Input data integrity check

Check the integrity of the input data, including the data type, length and range constraints of the scene, which are relatively easy to implement through configuration.

Rule processing between data items

Multiple data items can be processed by simple rules, including scene data mapping, data enrichment, data interception and so on. These are also supported in the mainstream traditional ESB bus products.

Custom scripting language

For the API rapid development platform itself can be used as a subclass of the low-code development platform, so if you can support custom scripting language for rule processing, then the overall scalability and flexibility will be greatly improved.

Header and output reservation

For the API interface released by the API development platform, it is necessary to specify the input message header, output exception type, exception coding, information and other fields in advance.

The input headers often include fields such as user name and Token that are used to access security verification, as well as related extended fields such as routing and paging. For the output field, you need to agree on the returned exception type, coding, exception information, and so on. Especially when it comes to data CUD operations, you need to output according to the agreed output fields.

Service composition and choreography

The API development platform can also further provide the ability of service composition and service orchestration. The implementation of this capability is not suitable for the API gateway, but should be planned to be implemented on the API development platform.

Service composition choreography is service composition, service assembly and so on. It is hoped that these things can be accomplished through service choreography, rather than simply completing the design and development of a single service. The ability to combine or assemble multiple atomic services together to form a new service and provide it. Let's give an example to illustrate.

For example, there are three atomic services, A _ Magi B _ C, and we form a new D service through service orchestration.

The three atomic services are all query services. We hope to assemble a new service and return the query results of three services at a time.

This is what we call service composition capability. for example, we can combine three basic atomic services: contract basic information query, contract clause information query, and contract execution information query, and finally return a service for comprehensive information query. Three query results are returned at a time.

In this scenario, we need to consider whether the query results are returned in parallel or hierarchically.

The atomic service of two query classes, which eventually needs to return the result set of the query associated with the two datasets.

This is often encountered after the microservice architecture has split the underlying database, such as the query for basic information of materials, and the query of purchase order details are provided in two separate database independent services. The query result set we want to return is the compound result set of item code, name, model, unit, price, and purchase quantity.

In this scenario, it is usually assembled when the front-end function is developed, but in fact, we can consider whether this problem can be solved at the service orchestration layer. It is easy to write code to solve this problem, but it is actually difficult to do it as a visual service orchestration configuration.

Tailor and enrich a single existing service to form a new service output

This temporarily brings it into the scope of service choreography, that is, it is still the input service, but the output provides a new service.

That is, tailoring and enriching a single existing service, such as filtering out some data items for the output results, fixed input items for input, and so on. These simple service tailoring, rich, or simple data transformations can be done at the time of service orchestration and provide a new service.

Concatenate multiple atomic services before and after the flow program to form a service provider

This is a kind of service orchestration scenario that we often see, that is, the three services of A _ Magi B ~ C are choreographed directly, that is, the output of A service becomes the input of B service, and the output of B service becomes the output of C service. If this is only assumed above, then the service orchestration of this flow program is still simple and easy to implement.

But in fact, the difficulty is that the output of A service itself needs to be the output of C service, and the output of AMagi B service may also be part of the overall output, which increases the difficulty of visual design of service choreography.

A single business service is a principal service, but orchestrating multiple business rule logic processing class services

This is also a common scenario. For example, when we import contract information, we first call the contract validity verification service, and also call the budget information check and deduction service to verify the integrity and business rules. After these verifications are completed, the actual contract information import service is called, and the failed result is returned directly if the verification fails.

This kind of service choreography is often the logic that we actually assemble the services when we develop the front-end functions.

Multiple import services are assembled into one import service to merge and import to form a new service

This scenario actually corresponds to scenario 1. Since multiple services can be combined to form a composite result, it is natural to merge multiple import services into a single import service and complete data import at one time.

For example, if there are two atomic services: project information import and project WBS information import, then we can provide a new project information import service to complete the import of project basic information and project WBS information at one time.

As can be seen in these scenarios, service choreography is actually common scenarios such as service concatenation, input and output merging under parallel services, rich service content and tailoring. In an ideal scenario, what we most want to achieve is that the implementation of a business function point can be completed through the visual design of service choreography.

Source code export

For API rapid development platform, it is difficult to implement complex business rule coding. Therefore, when there is a complex business rule implementation, it is still recommended that developers develop their own code to do it. Therefore, the whole platform should provide source code export function, and the exported source code should be able to compile directly, deploy and run away from the API development platform.

For the exported source code, considering the scenario of subsequent API interface changes, it is recommended to agree on the extension part.

For example, a standard API interface service implementation method can add extension processing before and after.

/ / BeforeDo (); / ProcessAPI (); / / AfterDo ()

In this way, additional business rule processing and integrity checking can be carried out before the interface is implemented, and the output data can be further processed and processed before the interface returns data.

Micro-service application

Multiple objects or multiple API interface services can be packaged into a microservice application and then deployed and published. Therefore, a concept of micro-service set is introduced here to package the micro-service API.

Packaged micro-services can be exported as separate JAR packages for deployment, or they can be deployed directly on the API development platform. For the API development platform itself, it should be connected to the micro-service running platform.

At this point, the study on "how to understand the design of API rapid development platform" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.