Transferred from: http://www.aspku.com/kaifa/net/298780.html
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 post some sample code:
{"ResultCode": 1300, "Message": "Insufficient Permissions", "Data": null,}
{"ResultCode": "," "Message": "Logical Exception", "Data": null, "Detailerror": {"Errcode": 1601001, "errmsg": "The 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.
http://www.xxx.com/version number current version number: v1 Http://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.
Access-control-allow-methods:get,post, Optionsaccess-control-allow-credentials:trueaccess-control-allow-headers: According to the content of the request header, fill in
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!
The above WEBAPI realization of the separation of the front and back of the example is the small part of the whole content to share to everyone, I hope to give you a reference, but also hope that we support Aspku Source Library.
WebAPI implementing a front-end detach example