WebAPI for front-end separation

With the development of web technology, now all kinds of frameworks, front-end, back-end, countless. The pressure of the entire stack of engineers is getting bigger.

Now the front-end framework, can do a variety of web, but also can do a variety of apps, the front-end frame replacement more and more quickly, more and more.

The traditional model

Front-end and back-end debugging, modifications are very cumbersome. Often the front end with the back end is very painful, the back end is also too front-end trouble.

(no solution, can solve the matter, try not to mouth. Office should be standing up some, bandages, hemostatic strips, quick-acting to save the heart pills and other drugs. In order to prevent the escalation of the situation, the Office should strengthen the tool control regulations. ）

Front-end separation

Front-end According to the pre-agreed documents, you can touch the data, and then develop, test, debug the UI, posted to the line when the API interface into the API interface, can be done.

The front end of the future to add new features, modify the UI, self-modification, self-compiled update their own UI site, published online as long as the API interface on the line. Does not require trouble to the back end. Separation of the two work.

The backend needs to negotiate with the front-end interface, write good interface documents, in the interface function of communication with each other (in fact, the equivalent of the need to communicate with each other), once the interface document is set up, only by prior agreement to implement API interface is the port. Compile the project and publish it to the online server. can be finished.

The backend implements the Webapi interface and can also face various calls, such as PC-side web, mobile app, or other devices. One interface multiple calls, implementing code to go heavy.

Working Mode Analysis

Detach the front-end and back-end. Each of their own areas of focus on research. More effective to deepen the depth of technology.

The front-end separation mode, you need n front-end engineers and N-back-end engineers.

First, let's make a pact to return the basic format, such as XML or JSON. As a result, most front ends are like JSON, because JS is inherently JSON-enabled. I put out some sample code

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

  {    "ResultCode": "A",    "Message": "Logical Exception",    "Data": null,    "Detailerror": {    "Errcode": 1601001,    "errmsg": "Amount must be greater than >0"}  }

Return parameter description

Name of parameter	Type	Whether there must be	Description
ResultCode	Int	Is	Return code
Message	String	Is	Result description
Detailerror	Josn	Whether	Specific error
Data	Josn	Whether	Data

ResultCode

ResultCode	Description
1000	Success
1100	Server exception
1200	Identity Validation exception
1300	Insufficient permissions
1400	Pass-through parameter validation does not pass
1500	Version exception
1600	Business logic Exceptions
1700	System into the upgrade
1800	The interface is deprecated

Specific exception

This is a bit controversial place, there are a lot of business logic exceptions, out of user friendly hints. Some jerky and difficult to understand the error prompt, directly to the user, the user a face confused force. But the backend can not be modified into friendly hints, so it is not easy to debug, to find the cause of the problem.

In general, the front end can automatically modify friendly prompts to the user.

If the backend returns a string, the front end is written dead in the code, in case a day back end thinks the description is more in line with the scene, modifying the string. The enemy still has 30 seconds to reach the battlefield.

Recommendation: Try to use the exception code, you can see above the example posted, the use of the exception code. Each exception has a unique number, and the description can be changed. But the numbers are the same.

User exception (1601000)	Description
1601001	Account/Password Error
1601002	Account is frozen
1601003	The original password is incorrect

Version control

Each API has a version, in fact, for the app, if it is web-side, are directly upgraded because the B/s structure itself is the advantage of upgrading convenience, only need to update the server can be.

Version control is generally used in two ways

First: The URL is the same, and the version is written inside the HTTP header.

The second type: The version is written on the URL.

I recommend the second, more direct and convenient to understand. Example:

http://www.xxx.com/version number current version number: V1http://www.baidu.com/v1/usersecurity/login

API style

Now the popular API style is more, the most famous is the restful style.

According to my experience, completely walk the restful style is very difficult, may also be the level problem, in the team interior also must consider other member's level question. Our current API style still retains the previous style.

Example, v* represents the version number

Http://xx.com/v*/usersecurity/signout

HTTP verbs

Create/Modify/delete resources on the server using the Post method

Retrieving a resource or resource collection from the server using the Get method

Basic naming rules

Using camel-type nomenclature-Large hump method

Cross-domain processing

A cross-domain issue arises from the deployment of front-end and back-end APIs to different sites.

What is a homologous policy?

The same origin is the domain name, the protocol, the port. That is, if it is different, it is non-homologous.

The same-origin policy is a basic security function of the browser, non-homologous access, the browser will be rejected.

HMTL above the SRC address, you can specify any URL, form submission, you can submit to any URL.

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

Modern browsers almost always support a way to request cross-domain resources. This technique is called cors (cross-domain resource sharing)

There are two types of cors across domains

First, simple cross-domain.

The second, complex cross-domain.

Resolution: HTTP output headers Increase how nodes

Note that there is a front-end framework version, a high security requirement, you cannot use wildcards *, to specify a cross-domain domain name.

access-control-allow-origin:*

The following nodes can be filled, can not be filled, according to the actual situation, the discretion.

123	Access-Control-Allow-Methods：GET,POST,OPTIONSAccess-Control-Allow-Credentials：trueAccess-Control-Allow-Headers：根据请求头的内容，填写

　　

Note: A complex cross-domain is more expensive to perform than a simple cross-domain hassle. Because a complex cross-domain sends an options pre-request prior to the request, the response determines whether the server supports cross-domain. In other words, it was actually requested two times.

Cookie Scope

Different sites, how to general cookies?

In general, simply set the cookie scope to the top-level domain, and the browser will automatically take cookies when accessing the subdomain.

example, when accessing a level two domain name, cookies are passed by default.

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

Example

Here are some sample documents, the rest is not much to say

Basically, the details and attention points of the Webapi front and back end are recorded, and more details are needed for the reader to find the answers themselves during the development process. The essay is finished!

WebAPI for front-end separation