Why web services sucks!

Introduction

Periodically, when faced with various web services , I ask myself: “Why was it so complicated?”. We pay a lot of attention to development processes, code cleanliness, tests and methodologies. We write comments and create documentation. But at the same time, we pay too little attention to the underlying external system interfaces, web services.

All of the following can be attributed to various kinds of web services, but basically I’ll talk about SOAP web services.

Using

In the modern world, web services are used everywhere. Every day someone tears off his API for the whole world. Publishes the documentation and waiting for the influx of visitors.
')
By services, users will find out the weather, get information about traffic jams, read the latest news and learn about events. All social projects, such as facebook, twitter, vk, google, provide access to web services to their users. Immediately there are many convenient software clients. Who would have thought that a person would be able to share his experiences and thoughts in any place and at any time.
More and more public services are acquiring the same services. They can pay fines, receive valuable information, write applications and receive services.

Services increasingly bind the information systems that surround us.

Diversity

Technologies on the basis of which services are implemented are very diverse. Here and Rest-services, Soap, cryptography, various data transfer protocols, data compression technologies, synchronous / asynchronous data transfer, guaranteed delivery.

All this is exacerbated by different versions of technologies and services. To create compatible systems, it is necessary to put a lot of effort.

Who in the forest, and who ...

But how to use all this diversity? Here opinions differ. But we can safely say that many services, in fact, are not. The easiest way to verify this is with a series of statements:

This is a web service if:

• For it, you can create self-sufficient classes with automated tools in most popular languages ​​(java, .net, python, ruby, c ++, etc.);
• It does not need additional documentation;
• To use it, you do not need additional manipulations (open the port via telnet, download diagrams to yourself, etc.)
• Only common technologies are used.
• The entire interface of the service is described in it (wsdl, xsd). No any-type. All types are precisely defined.
• All types are defined using namespaces.
• For data compression is used MTOM.
• Uses standard headers guaranteed delivery, authorization, etc.
• UTF encoding and no Cyrillic and other characters in type descriptions

This is not a service if:

• Additional information is required to use the service.
• Wsdl and xsd do not fully describe the service interface.
• Used any-type
• Message routing is performed using soap-action
• Zip is used for data compression
• Attachments are grouped and packaged in one item.
• Invalid or undefined namespaces
• For service, it is impossible to create classes by automated means.
• To use the service, it is necessary to write additional code (data packing, etc.)
• When requests are transmitted duplicate information (write name in three four places request)
• In the requests, it is necessary to fill in optional attributes (system attributes, etc.) that are not needed from the point of view of obtaining information (“send this attribute in this attribute, otherwise our system will not understand the request”).
• Formats that are not supported by most clients are used.
• For information, you need to make several requests within one supplier (“first we get this line from here, and then we make a request here ...”)
• Different requests can be received for requests in one service (various response formats)
• Service has the most complicated structure that is used for all requests. It is better to have 10 simple entry points than one universal.
• There are dual attributes
• System information is transmitted in the body (body) of the message, and not the header (header). The message body must contain only the request data.
• Non-standard headers are used for authentication, routing, guaranteed delivery.

Single entry point

Well-designed service is self-sufficient. He describes his own, uniquely interpretable, interface. For him, just create classes and you can immediately start using. In the client code, only filling in the request attributes is performed, no additional manipulations. The data structure of the service is simple and straightforward.

All the same as in the code. The minimum level of nesting, self-documenting, the system of logical names of elements and types (SampleRequest in the answer looks shocking ...).

All services that do not meet these requirements can only be called imitations. Of course, they are similar, but if nobody can use the service, then this is the problem of the data provider.

Compression or optimization

Here everything is already invented. Passing base64. Too much? Then use MTOM. Anyway a lot? For web services do not transfer gigabytes, wake up! Transfer links to fast file storage. When a client needs your photos, documents, archives and other media information - he will download it. He does not need an additional load of 20 megabytes per request. Text information is transmitted through the services; everything else is not reasonably transmitted.

If a company does not use its product, then it is worth nothing

If the service provider does not use it himself, if he uses any special interaction rules, if he introduces some privileges for himself in the regulations, then this service cannot be used by definition. The supplier has created an incomprehensible service that he cannot work with him. You will not look at such services without sadness ...

Conclusion

Where did I find such services? Yes, they are everywhere! Even large players have incomprehensible technical solutions. Only with well-constructed services, you can achieve a high degree of integration and stability of many heterogeneous systems.