Quick start for ExtJS back-end

Mutual Understanding

Imagine the situation: you are a freelancer and work with Ext. One (or several) back-end developers are working remotely with you. Work goes fast and smooth. But it so happened that the developer of the server part changed. If a new colleague has experience with Ext - everything is fine. But if a person will write a back-end for Ext for the first time or write for the web for the first time (this also happens), then you will need to find a common language.

And here problems can begin ...

We'll have to spend time on a simple explanation of the protocol, explaining how the server should respond to certain requests. To avoid this, I prepared a document describing everything (well, or almost all the nuances of the standard Ext protocol). This document is presented under the cut.

Solving the problem of understanding

ExtJs takes full advantage of the REST interaction architecture. What it is and what they eat with have already been written on Habré:

REST vs SOAP. Part 1. Feel the difference

Tao Web Service. (Or so stop reinventing the wheel!)

The author of the first topic ( Artiom1988 ) - a huge human thanks for the table, she saved me a huge amount of time when communicating with developers. And I stole it (with minor changes) for my document.

Standard HTTP operations

URL	Get	POST	PUT	DELETE
example.com/ticket	Get a list of all tickets	Create a new ticket	Update the list of tickets	Remove all tickets
example.com/ticket/15 (where 15 is the ticket id)	We receive information on a specific ticket.	-	We change the ticket	Remove a specific ticket

Requests should work in cases where the URL contains the final slash (www.exam.com/ticket/) and when there is no slash (www.exam.com/ticket)

')

Each object (ticket, user, etc.) has an id field - a unique identifier in the form of an integer value.

Message format

All messages are transmitted in valid JSON.

Further, we will call the array constructions of the form:

[1,2,3,4,"",true, false, "34"] 

as the object of the type

 {"param1" : "value1", "param2" : true, "param3": 45} 

note that parameter names are always strings (in double quotes), parameter values ​​can be strings, numbers, and booleans (true and false)

The fields will be named parameter names, in the object above there are fields param1 and param2



Objects can include arrays, and arrays objects, for example

 { "success": true, "items" : [ { "name": "Vasya" }, { "name" : "Sveta" }] } 

Client request format

POST and PUT

Contains one items parameter, which is an object

 {"name":"123","id":0,"region_id":2,"region_name":""} 

Get

When requesting lists can contain standard parameters:

start - the number of the record with which the response begins

limit - the maximum number of returned records

filter - an array containing the objects of the form

 {"property":"name","value":""} 

those. GET request

/users?start=40&limit=20&filter=[{"property":"name","value":""}]

(the query is naturally uri encoded) should return 20 users named Vasya, skipping the first 40 of the database.

It’s good practice to use filters for filtering with full text filter names like the required field + string "_like". Those. filter

 {"property":"name_like","value":""} 

will find and Vasiliev and Vasilis. Porameters with full-text search are naturally negotiated.

Server response format

The answer is always an object.

There must be a field of success , which can take boolean values.

Answers to GET requests

If a list of items is requested, the response should contain a total field, which is an integer indicating the total number of rows in the database for this controller (i.e., if we specified the filter and limit parameters and received several records, then the total still indicates the number of entries).

If a specific item is requested ( exmple.org/users/5 exmple.org/users/5 ), then the total field is not set.



The data itself is in the items field, which is an array containing data objects.

 { "items":[{ "region_id":2, "name":"Moscow", "id":25 },{ "region_id":1, "name":"Piter", "id":18 }], "success":true, "total":2 } 

If one object was requested, the array is not used.

 { "items":{ "region_id":2, "name":"Moscow", "id":25 },{ "region_id":1, "name":"Piter", "id":18 }, "success":true } 

Responses to DELETE requests

 {"success":true} 

- It's enough

Answers to POST and PUT requests

Similar to a response to a GET request, when requesting a specific object, they only have to return already changed data.

Errors

In case of errors, the success field is false , the errors field is also added - an array of strings describing errors

 {"errors":["Object not found"],"success":false} 

Data naming

If the object needs to refer to another object, the parameter with the prefix _id is used , i.e. if the server returns a city object, and the city is in a region, the answer may be of the following form:

 {"region_id":2,"name":"Moscow","id":25} 

If necessary, the region_name field containing the name of the region can be added (and in the database it works as a field that is cached in the city table).



When one object contains a lot and you need to get a nested hierarchy, an array field with a plural name is used, i.e. If a region is requested, to which several cities are attached, the answer may be:

 { "id":2, "name":"Central", "cities" : [{ "name": "Moscow", "id":2 },{ "name":"New York", "id":3 }] } 

Backend testing methodology

For testing, you can use the wonderful Google Chrome extension.

1. Sending a GET request (there must be at least one item in the database per server)
2. Sending a POST request containing all or necessary data. The response should come information on the new item.
3. Sending a GET request and checking for the presence of the item created in clause 2
4. Sending a PUT request to change an item created in clause 2 and received among others in the list in clause 3. The response should include information on the changed item
5. Sending a GET request and checking the change created in paragraph 4 of the item
6. Sending a DELETE request to delete an item created in clause 2. The response is confirmed.
7. Sending a GET request and checking for the absence of the item created in clause 2

Conclusion

Perhaps this document will be useless to someone, and to someone, like me, will save some valuable time.