Client (Android,ios) communicates with the server

Android,ios client-to-server communication
For ease of understanding, use PHP directly as a server-side language

is actually an HTTP request response process sequence,
Start with the B/S mode.
The browser initiates an HTTP request, the server responds to the request, and returns the data to the browser, which is rendered by the browser, which is the effect we see

Client (Android,ios)
Android implements HTTP requests via network requests such as HttpClient or URLConnection, (equivalent to a browser, sending a URL request), which accesses the server,
The server responds to the request and returns the result to the client, which is rendered by the client, which is the effect we see.

iOS implements HTTP requests via network requests such as Nsurlrequest,nsurlconnection,afnetworking, (equivalent to a browser, sending URL requests),
That is, to access the server, the server responds to the request, and returns the results to the client, rendered by the client, which is the effect we see.

During the client-side request process, client development and server development develop a rule, for example: the server says that I have formatted the response data in JSON or XML,
Let your clients render the style themselves, and this completes the basic request.

And then from maintaining session state:
Start with the B/S mode.
When the browser requests the server, it sends the information about the cookie (which is not prohibited by the browser) to the server via the header, which is accessed by the browser
Server, this information is sent to the server by default, so the PHP server can directly use $_cookie to extract information.
Here again, the principle of maintaining a conversation between cookie,session.

When you first visit a Web site (if you have not previously visited, or clear a clean-related cookie), the server automatically generates a session,
and saves the information about the session in the server, Session_name (), session_id (),
(assuming the default session mechanism, session_name () = = PHPSESSID),
then put Session_name (), session_id (), back to the browser, and save it in a cookie, where The value of Session_name () (that is, PHPSESSID)
as the name of the cookie, and the value of session_id () as the value of the cookie, the session ID of the browser and server is established. When the browser requests again,
The cookie-related information is sent to the server side, the server obtains the cookie information, compares the session related information, if corresponding, is the same as the
one identity request, thus establishes the session identity State.

Again from the client (Android,ios)
is actually the mechanism of simulating the cookie and the session
Because the client does not have a cookie (or it can be used, that is, not here), the server can generate a session each time it is requested, but cannot
The way the cookie is saved on the client, the confusion is here? Assume that the user first installs, or clears, the relevant information. You can set the rules for this and the client,
is to set an identity, here, we call token, when the client first accesses, the token passed over is empty, the server receives the client initiated request,
Found token is empty, so just generate a unique token on the server and save it on the server side (can choose to save in database, Memcached,redis, etc.),
Then the content of the response is returned to the client, and tokens are passed together, and the token value can be updated when the client receives the token,
When requested again, the token is also passed over, the server accepts the request, and resolves the token, compared to the server, if present, updates the token lifetime,
And that is the same user request, so that a session ID is established. The equivalent of a cookie is compared to a session. As to how token is saved on the client
, in fact, the client has its own mechanism, for example, the client can generate a file, and then save the token value inside, each request, read this
file, and take the value to request the server, so that the connection is established.

That's more general. As with cookies, tokens have a life cycle. So how can you set the token effective period like a cookie? In fact, the principle is
The same is true when the client requests the server, each time the server token's validity period is updated. When the server returns to the client, the client also updates each time
Token is valid for the duration of the token.

The following simulation of a customer purchase process, the token, user ID (userId) in the database (a separate table, such as: token_table),
Also put the shopping cart products in the database (another table such as: cart_table). Allows users to add products to the shopping cart without logging in.
When the user adds a product to the shopping cart, the token is passed, and tokens are used to identify it, each time the client requests,
The token is also passed to the server to determine the same user. If the user submits the order, it will be logged in, at this time,
Check the Token_table table, in comparison with the token field, if the UserID is empty, the user is not logged in, and the message is returned to the client.
Notify the user to login, and then the user login, through the message, if the login is successful, then update the UserID field of the Token_table table, indicating that the landing was successful,
and return the success status to the client, at this time to establish a login status, at this time, if it involves in the server order submission, payment and other information,
Generally will use UserID as the logo, at this time, you have to use token to query the Token_table table, from which to remove the UserID, so you can complete the relevant operation.

Client (Android,ios) communicates with the server