How to Implement AJAX without relying on backend Interfaces

What is the problem?
There are more and more ajax requests on the web page, or applications have been using ajax to exchange data with the backend since the beginning. (Currently, I am involved in this project.) It is a headache to debug the frontend and backend of multiple interfaces.
It is impossible for the backend to write all interfaces in a short time, nor to create fake data and interfaces for front-end testing, not only is it time-consuming, but the data structure and Interface Name returned during the development phase may also be changed. This looks good if the backend writes an interface to the front end. However, in the specific implementation process, there may be errors in the interfaces that are not completed at the backend. You need to constantly communicate with the backend to find the reason. It may also be stuck waiting for the backend to return positive data.
To continue.

Why?
1: the front-end depends on the unformed interface at the early stage of development.
2: the backend does not fully understand the data items and data formats required by the front-end.
How can this problem be solved?
1: The frontend and backend of the requirement validation meeting fully discuss functions and interfaces. (The backlog with clear requirements is very simple)
Under the premise of a complete backlog document, each user's operation is recorded as a clear function. As long as the developers agree with these entries in the final confirmation, it is easy to summarize the required interfaces.
2: frontend write interface documentation (backend assistance ).
Why is it a front-end?
1: the front-end fully understands the data to be displayed on the page. 2: the front-end fully understands the required data format (how to handle error codes, etc)
The frontend interface document may be as follows: (sample logon Interface)
Copy codeThe Code is as follows:
: User Logon
Url :? (Left for backend supplement)
Request Method: POST
Request Parameter: email: String
Pwd: String
CheckCode: String
Returned data:
{
Code: int, // error code. If logon succeeds, it is 0. If other errors are returned, the error code is returned. No result item is returned.
Result :{
Id: int // user id
Name: string // User name
...
}
}

How does the backend assist?
1: Fill in the request url. 2: Correct the returned data fields. If the fields in many returned data items do not comply with the backend development fields, the backend needs to be modified.
Modifying a document is a process of discussion at the frontend and backend. You can communicate with each other if you have any questions. After the documents are completed, separate them. (Other colors can be used for any changes in the document to remind other personnel of the changes)
After the backend configuration is complete, it may be like this:
Copy codeThe Code is as follows:
: User Logon
Url: user/login. php (Supplement)
Request Method: POST
Request Parameter: email: String
Pwd: String
CheckCode: String
Returned data:
{
Code: int, // error code. If logon succeeds, it is 0. If other errors are returned, the error code is returned. No result item is returned.
Result :{
Id: int // user id
User: string // user Name (modified)
...
}
}

3: the development process is fully documented
After the document is completed, we all know that as long as I do this, it is true to return and use such data.
The back-end begins to write code, so you don't have to worry about the front-end. It won't bother you.
How does the front end start working according to the document?
All interfaces are available, and the returned data is also available. The next step is to build a framework that can use simulated data testing.
If jquery is used, a simple structure may be like this.
The user clicks the login button. The front-end simulates the data described in the document and directly calls the callback function. This is the same as the actual situation.
Copy codeThe Code is as follows:
View Code
Common = {
Post: function (url, data, success) {// a basic post request Encapsulation
$. Ajax ({
Url: url,
Type: "post ",
Data: data,
DataType: "json ",
Error: function (){
// Common. tip (TipData ["1002"], 0 );
// Ajax error message
},
Success: function (data ){
If (data & data. code! = 0 ){
// Common. showError (data );
// The error handling code is converted into a text prompt to the user
};
Success & success (data );
}
});
}
};
// 1: User Logon
Function login (email, pwd, checkCode, callback ){
// Test environment
Var data = {// simulate data
Code: 0,
Result :{
Id: '20140901 ',
User: "lujun"
}
};
Callback (data); // directly pass the simulated data to the callback function
Return;
// --- Comment out the above Code when linking the real data. The comments will be removed after the compression tool is released.
// Formal environment
Common. post ("user/login. php", {email: email, pwd: pwd, checkCode: checkCode}, callback );
};
// Click event-driven Logon
// Log on successfully and execute some column actions
$ ('# Submit'). click (function (){
Var email = $ ('# email'). val ();
Var pwd = $ ('# pwd'). val ();
Var checkCode = $ ('# checkcode'). val ();
// Call the logon Interface
Login (email, pwd, checkCode, function (data ){
If (data & data. code = 0 ){
// Ajax execution successful
Data = data. result;
$ ('# Username'). text (data. user );
// Other code...
}
});
});

How can we work better?
All functional interfaces work in this way, and you will find that the entire application does not require backend support. You can use simulated data to complete the acceptance test. Is it cool!
Once you have prepared a link to the official data, comment out the test code (this may be distributed in every corner of the Code, 10 places or more ). You cannot quickly switch between a test environment and a database connection environment!
The value of such a test code is too limited.
We can separate the test data as a file and overwrite the underlying AJAX request method by means of method coverage.
Copy codeThe Code is as follows:
View Code
// TestData. js is used to store all test data
TestData = {
"Userlogin": {// test data for Logon
Code: 0,
Result :{
Id: '20140901 ',
User: "lujun"
}
}
//... Testing other structures
};
// Common. js
// Overwrite the Common. post Method
Common. post: function (url, data, success) {// a basic post request Encapsulation
// It is also a good idea to use the url MD5 as the key, which can save so many judgments.
If (url = "user/login. php "){
Success (TestData ["userlogin"]);
} Else if (url = "other") {// other interfaces
//...
}
};
// 1: User Logon
Function login (email, pwd, checkCode, callback ){
Common. post ("user/login. php", {email: email, pwd: pwd, checkCode: checkCode}, callback );
};
// Click event-driven Logon
// Log on successfully and execute some column actions
$ ('# Submit'). click (function (){
Var email = $ ('# email'). val ();
Var pwd = $ ('# pwd'). val ();
Var checkCode = $ ('# checkcode'). val ();
// Call the logon Interface
Login (email, pwd, checkCode, function (data ){
If (data & data. code = 0 ){
// Ajax execution successful
Data = data. result;
$ ('# Username'). text (data. user );
// Other code...
}
});
});

The above code is easy to understand and overwrites the underlying ajax Request Method When simulating data testing.
Of course, this is only one of them. You may have a better method or use a global variable to switch two environments, as if debug = false and debug = true!
Last
The method is actually very simple, but it is important to break down and understand the backlog in scrum.
My team now works very well in this way.
Finally, I have been thinking about how to organize code for an application with 500 K JS compressed by obfuscation?