Examples of WebAPI Implementation of frontend and backend separation, webapi examples

Examples of WebAPI Implementation of frontend and backend separation, webapi examples

With the development of Web technology, there are countless frameworks, front-end and backend. Full-stack engineers are under increasing pressure.

Currently, front-end frameworks can be used for both various Web and various apps. Front-end frameworks are updated more and more quickly.

Traditional Mode

Debugging on the frontend and backend is troublesome. It is often difficult for the frontend to work with the backend, And the backend is also troublesome.

(If you have no idea, do not talk about what you can do. The Office should keep some medicines such as bandage, hemostatic strip, quick-acting rescue pills, etc. To prevent the upgrade, the Office should strengthen the tool control regulations .)

Frontend and backend Separation

Based on the pre-defined documents, the front-end can touch the data, develop, test, debug the UI, and change the API interface to the online API interface when publishing it online.

New functions will be added to the front-end in the future. You can modify the UI, compile and update your UI site, and call the online API to publish the website. It does not need to bother the backend. The two work is separated.

The backend needs to discuss the interface with the front-end, write the interface document, and communicate with each other on the interface function (in fact, it is equivalent to communicating with each other). Once the interface document is set, you only need to implement the API interface as agreed in advance. Compile the project and publish it to the online server. You can complete the process.

The backend implements WebApi interfaces and can also face various calls, such as PC web, mobile APP, or other devices. Multiple calls to an interface are implemented to remove code duplicates.

Working Mode Analysis

Separate the frontend and backend. Perform their jobs and focus on their own fields. More Effectively deepen the technical depth.

In the frontend and backend separation mode, you need N front-end engineers and N back-end engineers.

First, we need to specify some basic response formats, such as XML or JSON. As a result, most front-ends prefer JSON, because JS naturally supports JSON.

I posted some sample code:

{"ResultCode": 1300, "Message": "insufficient Permissions", "Data": null ,}

{"ResultCode": 1600, "Message": "logical exception", "Data": null, "DetailError": {"ErrCode": 1601001, "ErrMsg ": "The amount must be greater than> 0 "}}

Response parameter description

Parameter Name	Type	Required?	Description
ResultCode	Int	Yes	Return code
Message	String	Yes	Result description
DetailError	Josn	No	Specific Error
Data	Josn	No	Data

ResultCode

ResultCode	Description
1000	Successful
1100	Server exception
1200	Authentication exception
1300	Insufficient Permissions
1400	Passed parameter verification failed
1500	Version exception
1600	Business Logic exception
1700	The system is being upgraded.
1800	This interface has been deprecated

Exception

This is a bit controversial. There are a lot of business logic exceptions, out of user-friendly prompts. Some obscure error prompts are directly sent to the user, and the user is overwhelmed. However, the backend cannot be changed to a friendly prompt, which makes debugging inconvenient and finds the cause of the problem.

Generally, the front-end can automatically modify the friendly prompt to the user.

If the backend returns a string and the front end is written to the Code, the backend considers the description to be more in line with the scenario and modifies the string one day. The enemy will arrive at the battlefield in 30 seconds.

Suggestion:Try to use the Exception Code. You can see the Exception Code that is used in the example above. Each type of exception has a unique ID, and the description can be changed. But the number does not change.

User exception (1601000)	Description
1601001	Incorrect account/Password
1601002	Account frozen
1601003	Incorrect original password

Version Control

Each API has a version, which is actually targeted at the APP. If it is a WEB end, it is directly upgraded because the B/S structure itself has the advantage of convenient upgrade, you only need to update the server.

Two methods are generally used for version control.

First:The URL remains unchanged, and the version is written in the HTTP header.

Second:The version is written on the URL.

I recommend the second method, which is more convenient to understand. Example:

Http://www.xxx.com/ v:v1http://www.baidu.com/v1/usersecurity/login

API Style

Currently, there are many popular api styles. The most famous is the restful style.

Based on my own experience, it is very difficult to completely adopt the restful style, which may also be a level problem. In the team, we should also consider the level of other members. Currently, the API style is retained.

For example, V * indicates the version number.

http://xx.com/V*/UserSecurity/SignOut

HTTP predicates

Use the Post method to create, modify, and delete resources on the server

Use the Get method to retrieve a resource or resource set from the server

Basic naming rules

Use the camel naming method-big hump method

Cross-origin Processing

Cross-origin problems may occur when the frontend site and the backend API are deployed to different sites.

What is a same-origin policy?

The same source is a domain name, protocol, and port. That is to say, if they are different, they are not the same source.

The same-origin policy is a basic security function of the browser. If you do not access the same-origin policy, the browser rejects the policy.

You can specify any URL and form submission for the SRC address above HMTL. You can submit the URL to any URL.

However, if you use AJAX technology, it will be affected by the same-origin policy and refuse to submit.

Almost all modern browsers support cross-origin resource requests. This technology is called CORS (cross-origin resource sharing)

CORS is divided into two types:

First, simple cross-origin.

Second, complex cross-origin.

Solution: how to add nodes to the HTTP output Header

Note that there is a front-end Framework version, which has high security requirements and does not support wildcard characters *. You must specify a cross-domain name.

Access-Control-Allow-Origin：*

The following nodes can be entered. You can leave them empty. You can decide based on the actual situation.

Access-Control-Allow-Methods: GET, POST, OPTIONSAccess-Control-Allow-Credentials: trueAccess-Control-Allow-Headers: Enter

Note: complex cross-origin is more troublesome than simple cross-origin, and more cost-effective. Because the complex cross-origin request starts an options pre-request before the request, the server determines whether to support cross-origin based on the response. That is to say, the request is actually made twice.

Cookie Scope

How do I use Cookies for different sites?

Generally, you only need to set the cookie scope to a top-level domain name. the browser will automatically include cookies when accessing the subdomain name.

For example, when accessing a second-level domain name, cookies are transmitted by default.

Top-level domain name: baidul. comcookies scope: .baidu.com second-level domain name: www.baidu.comapi.baidu.com

Example

I will post some sample documents below, so I will not talk about them more.

Basically, the details and points of attention of WebApi frontend and backend separation are recorded, and more details need to be found by the readers themselves during the development process. All done!

The preceding example of WebAPI front-end and back-end separation is all the content shared by Alibaba Cloud. I hope you can give us a reference and support for the customer's home.