Good client-server architecture
Immediately make a reservation that I am a mobile developer, and the article is intended mainly for developers on the other side of the cloud - mobile workers know everything about it. I wrote the last web application many years ago and can be mistaken in web terminology without knowing some of the latest trends in .NET, PHP or Java web services, so do not judge strictly.
Like any front-end developer, in almost every project I have to deal with client-server protocols - without them in any way. And very, very often you have to work with poorly designed architecture.
Also, very often the development of the protocol and architecture falls on the shoulders of the web developer, which is not always true - in most cases it should be developed only together with those who will adapt to this architecture. Unfortunately, over the past three years, working on several dozens of projects, I have been involved in planning this area of ​​architecture only 3 or 4 times - in all other cases it has already been provided by the customer at different levels of readiness. But how much better the world could be!
Most often I came across something like this:
')
Those. the result of processing the request is contained in the XML itself, the HTTP return code is 200, i.e. Normally, data is presented as normal RPC. For example, error handling in SOAP is implemented in a similar way in 90% of cases.
In especially neglected cases, especially characteristic of the Hindu code, false can be in various places of XML, which significantly complicates parsing, leads to over-complicated and immensely happy bored programmer.
But let's consider the shortcomings of this approach in principle.
But the time needed by the web programmer to invent the text of the message is wasted, and even the channel is loaded with unnecessary information.
How to solve a problem?
For many years now HTTP protocol has been able to add its own error codes, for this they simply have to belong to the range from 512 to 597. I am sure that this amount of errors is enough to cover all possible errors in a medium-sized application. Obviously, what advantages it gives, but still summarize:
It will also be interesting to see how the HTTP standard and the English-language Wikipedia look at this situation:
Those. Clients should show the user a message sent by the server. It is immediately evident that the Americans wrote. Russian, by the way, stupidly translated .
Although we will not generalize - the idea of ​​using HTTP codes was suggested to me by an American several years ago.
In general, the ideology is that the client always knows better how to report an error. And the server must inform the client about the error in the fastest and least costly way.
Such a binding occurs, most likely, if a website was first created, and only then the customer decided to make a mobile frontend. Although working with session variables is possible from the mobile side, this is not a good practice, since often there is no normal tool for working with these tools.
The second, global flaw is that Safari (or any browser on Android) does not scrub their cookies and session variables with the application, which, of course, is correct from the point of view of security, but leads to a number of problems and crutches.
Suppose your mobile application implements only 70% of the website functionality. The remaining 30% of the functionality is available only on the web, and your application only contains links to relevant web pages.
Also, perhaps these pages are available only to authorized users. As a result, the user who has already logged into the mobile client will be prompted to log in again - now into an inconvenient web form, and it will be fortunate if the user is redirected to the desired section of the site after the login.
Conclusion - if you are designing a universal protocol, forget about such things as session variables and cookies. A much better way would be to transfer some unique token received during authorization, clearly in the body of each request. And web pages and web applications - to adapt to the use of a single API. I’m sure all mobile developers have often seen two versions of the API - one for web applications, the other for mobile. But this is a duplication of functionality, which is always more expensive both at the development stage and at the debugging stage. It is always better to allocate web services from the very beginning into a separate layer of the system, rather than be embedded into other parts close to web technologies.
HTML return
This is already rooted in the device of the web servers themselves, which were originally sharpened just for the browser. Errors 403, 404, and sometimes more complex ones are often given in the form of an HTML page, which often simply does not have the means to display in a mobile application. More precisely, the funds are there, but after seeing “404 page not found” with a hefty black Arial Black on a white background inside the web view, the mobile user will be frightened and close the application.
Remember, the server should give XML (or JSON) to any access to web services, and only in the format that was originally specified. Mobile developer can not do anything worthwhile with the HTML that comes from the server.
Use WSDL
The situation with Microsoft technologies is still nothing - most of their modern technologies support WSDL out of the box. What can not be said about PHP and Java - especially PHP-developers love to create manually the usual pages, which are essentially web services. But in order to integrate with a WSDL-compatible web service, a mobile developer only needs to use the tool to generate code, while web-service responses compiled by “manual” also need to be parsed with “hands”.
True, there are subtleties here - the standard WSDL implementations from MS and Sun (Oracle) still have incompatibilities, but still it’s faster to fix these incompatibilities with a file than to write everything manually.
I only touched upon the most painful design errors that mobile developers face day after day. If the article is in demand, I will definitely write about a dozen client-server subtleties that I would love to see in the API of web services that you work with every day.
Like any front-end developer, in almost every project I have to deal with client-server protocols - without them in any way. And very, very often you have to work with poorly designed architecture.
Also, very often the development of the protocol and architecture falls on the shoulders of the web developer, which is not always true - in most cases it should be developed only together with those who will adapt to this architecture. Unfortunately, over the past three years, working on several dozens of projects, I have been involved in planning this area of ​​architecture only 3 or 4 times - in all other cases it has already been provided by the customer at different levels of readiness. But how much better the world could be!
Error processing
Most often I came across something like this:
')
HTTP code 200 (OK) <?xml version="1.0" encoding="utf-8"?><Body> <Result> <Success>false</Success> <Error>The username or password is incorrect. Please try again.</Error> </Result> <Response> </Response> </Body> Those. the result of processing the request is contained in the XML itself, the HTTP return code is 200, i.e. Normally, data is presented as normal RPC. For example, error handling in SOAP is implemented in a similar way in 90% of cases.
In especially neglected cases, especially characteristic of the Hindu code, false can be in various places of XML, which significantly complicates parsing, leads to over-complicated and immensely happy bored programmer.
But let's consider the shortcomings of this approach in principle.
- First, it is necessary to parse XML. This is extra data transmitted over the network, extra processor time spent on parsing XML, extra RAM for storing text data. All this is not so bad on modern devices in the Wi-fi zone, but even such excesses can make a difference in the metro between stations in the application that sends dozens of requests at the same time (indeed, with this approach, empty blocks for error handling should be in every request, even successful).
- Secondly, a web developer has to invent error texts himself. Very often they are completely incomprehensible to the user, because The accuracy of the wording is the last thing the web developer thinks about when writing the service. The text of the error in 90% of cases is not consistent with the native speakers and the last, but most important, a huge number of mobile applications need localization. While the text of the error, most likely, is always written only in English, hence it is absolutely useless for front-end programmers - it cannot simply take it and display it.
But the time needed by the web programmer to invent the text of the message is wasted, and even the channel is loaded with unnecessary information.
How to solve a problem?
For many years now HTTP protocol has been able to add its own error codes, for this they simply have to belong to the range from 512 to 597. I am sure that this amount of errors is enough to cover all possible errors in a medium-sized application. Obviously, what advantages it gives, but still summarize:
- No redundancy. Only the HTTP code in the header is transmitted, the body of the request is simply not there.
- On the client side, there are only two branches of the request processing code — successful execution, or an error during execution (both callbacks are already implemented out of the box in any query library). There are no branches “the request was executed successfully, but a logical error may be in the body of the answer”.
It will also be interesting to see how the HTTP standard and the English-language Wikipedia look at this situation:
5xx Server Error
The server failed to fulfill an apparently valid request. [2]
If you’re aware of the number “5” You must be able to make a request. Likewise, user agents. These response codes are applicable to any request method.
Those. Clients should show the user a message sent by the server. It is immediately evident that the Americans wrote. Russian, by the way, stupidly translated .
Although we will not generalize - the idea of ​​using HTTP codes was suggested to me by an American several years ago.
In general, the ideology is that the client always knows better how to report an error. And the server must inform the client about the error in the fastest and least costly way.
Binding to a session or cookie.
Such a binding occurs, most likely, if a website was first created, and only then the customer decided to make a mobile frontend. Although working with session variables is possible from the mobile side, this is not a good practice, since often there is no normal tool for working with these tools.
The second, global flaw is that Safari (or any browser on Android) does not scrub their cookies and session variables with the application, which, of course, is correct from the point of view of security, but leads to a number of problems and crutches.
Suppose your mobile application implements only 70% of the website functionality. The remaining 30% of the functionality is available only on the web, and your application only contains links to relevant web pages.
Also, perhaps these pages are available only to authorized users. As a result, the user who has already logged into the mobile client will be prompted to log in again - now into an inconvenient web form, and it will be fortunate if the user is redirected to the desired section of the site after the login.
Conclusion - if you are designing a universal protocol, forget about such things as session variables and cookies. A much better way would be to transfer some unique token received during authorization, clearly in the body of each request. And web pages and web applications - to adapt to the use of a single API. I’m sure all mobile developers have often seen two versions of the API - one for web applications, the other for mobile. But this is a duplication of functionality, which is always more expensive both at the development stage and at the debugging stage. It is always better to allocate web services from the very beginning into a separate layer of the system, rather than be embedded into other parts close to web technologies.
HTML return
This is already rooted in the device of the web servers themselves, which were originally sharpened just for the browser. Errors 403, 404, and sometimes more complex ones are often given in the form of an HTML page, which often simply does not have the means to display in a mobile application. More precisely, the funds are there, but after seeing “404 page not found” with a hefty black Arial Black on a white background inside the web view, the mobile user will be frightened and close the application.
Remember, the server should give XML (or JSON) to any access to web services, and only in the format that was originally specified. Mobile developer can not do anything worthwhile with the HTML that comes from the server.
Use WSDL
The situation with Microsoft technologies is still nothing - most of their modern technologies support WSDL out of the box. What can not be said about PHP and Java - especially PHP-developers love to create manually the usual pages, which are essentially web services. But in order to integrate with a WSDL-compatible web service, a mobile developer only needs to use the tool to generate code, while web-service responses compiled by “manual” also need to be parsed with “hands”.
True, there are subtleties here - the standard WSDL implementations from MS and Sun (Oracle) still have incompatibilities, but still it’s faster to fix these incompatibilities with a file than to write everything manually.
Conclusion
I only touched upon the most painful design errors that mobile developers face day after day. If the article is in demand, I will definitely write about a dozen client-server subtleties that I would love to see in the API of web services that you work with every day.
Source: https://habr.com/ru/post/150375/
All Articles