Quick start for ExtJS back-end

Understanding problem

Imagine a situation: you are a freelancer and work with Ext. One (or several) back-end developers works remotely with you. Work is fast and smooth. But it so happened that the developer of the server side has changed. If a new colleague has experience with Ext, everything is fine. But if a person first writes back-end for Ext or first time writes for the web (this also happens), then you will need to find a common language.
And here problems can start ...
We 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 protocol for Ext). This document is presented under the cut.

The solution to the problem of understanding

ExtJs takes full advantage of the REST interoperability architecture. What is it and what they eat with have already written on the hub:
REST vs SOAP. Part 1. Feel the difference
Tao Webservice. (Or yes stop reinventing the bicycles!)
To the author of the first topic ( Artiom1988 ) - many human thanks for the table, it saved me a huge amount of time when communicating with developers. And she (with minor changes) I stole for my document

Standard HTTP operations

URL	Get	Post	Put	DELETE
example.com/ticket	Get a list of all tickets	Create a new ticket	Updating the list of tickets	We remove all tickets
example.com/ticket/15 (where 15 is the ticket id)	Get information on a specific ticket	-	We change the ticket	Delete a specific ticket

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

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

Message format

All messages are sent in valid JSON.
Next, we will call an array constructions of the form:

[1,2,3,4,"строка",true, false, "34"]

and the object of the construction is

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

note that parameter names are always strings (in double quotes), parameter values ​​can be strings, numbers and boolean (true and false)
Parameter names will be called fields, in the object above there are param1 and param2 fields.

Objects can include arrays, and arrays objects , eg

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

Customer 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, it can contain the standard parameters:
start - the number of the record with which the response begins
limit - the maximum number of returned records
filter - an array containing objects of the form

{"property":"name","value":"Вася"}

those. A GET request
/users?start=40&limit=20&filter=[{"property":"name","value":"Вася"}]
(the request is naturally uri encoded) should return 20 users with the name Vasya, skipping the first 40 from the database.
It’s good practice to use filters with full-name filtering with names like the search field + the string "_like". Those. filter

{"property":"name_like","value":"Вас"}

will find both Vasiliev and Vasilis. Parameters that have full-text search are naturally worth specifying.

Server response format

The answer is always an object.
There must be a success field , which can take Boolean values.

Responses to GET Requests

If a list of items is requested, then the response should have a total field , which is an integer that shows the total number of rows in the database for this controller (i.e. if we specified filter and limit parameters and got several records, then total does not matter indicates the number of entries).
If a specific item ( exmple.org/users/5) is requested , 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, then 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 Queries

{"success":true}

- It's enough

Responses to POST and PUT requests

Similar to the response to a GET request, when requesting a specific object, it should only return already changed data.

Mistakes

In the case of field errors success equal to false , so the field is added errors - an array of lines of error description

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

Data naming

In case the object needs to refer to another object, the parameter with the _id prefix is used , i.e. if the server returns an object-city, and the city is in a region, then 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 working in the database 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 name in the plural is used, i.e. if you request a region to which several cities are attached, then the answer may be:

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

Backend Testing Methodology

You can use the wonderful Google Chrome extension for testing.

1. Sending a GET request (there must be at least one item in the database on the server)
2. Sending a POST request containing all or necessary data. The response should include information on a new topic.
3. Sending a GET request and checking for the presence of the item created in paragraph 2
4. Sending a PUT request for changing the 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 of the item created in paragraph 4
6. Sending a DELETE request to delete the item created in step 2. A confirmation message is returned.
7. Sending a GET request and checking for the absence of an item created in paragraph 2

Conclusion

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