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

Recently, an article was published on Habré under the provocative headline and a call to stop the inventions of bicycles in the API structure. Since the topic is interesting to me, I just could not pass by.
Alas, the reality behind the habrakat greatly disappointed me - I saw another bike, and even with square wheels. (Colleagues, nothing personal, just a technical discussion.) True, the authors honestly said that they saw the fashionable word REST on several sites and decided to do it. Only here they understood this “REST” in their own way, just like Ded Shchukar read and understood the explanatory dictionary.
In this topic, I urge to really do away with the bikes in the API sites. After all, it turns out what anecdote: the IPA is designed to simplify access to the site and ease of connecting external systems, but it turns out that it is even more difficult with it than without it :)

Just below the cut, I will sign the death sentence on all bikes in the universal API. Not to be unfounded, I will illustrate with examples.
But I must warn you right away - after reading the article, you will not be able to look at Vasya Pupkin’s next bike under the proud name “universal API of the site” without a gag reflex.

The narration will address the following questions:

')
So for today the most common ways to access the API of sites are:
1. XML-RPC.
2. REST (with the proviso that this is not a protocol, but an approach).
3. SOAP.

Basic technology and comparison

XML RPC

I think I’m not going to make a mistake if I say that XML-RPC is the progenitor of all this nonsense, which we now call with loud words “web services” and “web-site api”. It was developed in 1998 by order of Microsoft. At its core, this is the reincarnation of the good old RPC using XML message formatting. The undoubted advantage of the protocol is its simplicity, and as a result, ease of implementation.
Here is an example of a typical XML-RPC request:

  <? xml version = "1.0"?>
  <methodCall>
    <methodName> examples.getAirportCode </ methodName>
    <params>
      <param>
          <value> <i4> 567 </ i4> </ value>
      </ param>
    </ params>
  </ methodCall>

You can get the same simple answer:

  <? xml version = "1.0"?>
  <methodResponse>
    <params>
      <param>
          <value> <string> SVO </ string> </ value>
      </ param>
    </ params>
  </ methodResponse>

The error messages look just as easy. This answer can be easily parsed even to a person, not to mention a car. Such simplicity served him a double service: on the one hand, he was not accepted by the customer and did not become a standard, but on the other, he liked the crowd of simple, unbleached programmers. These guys needed a simple and reliable means of exchanging information between systems, they did not want to bother with such crap as a beautiful URL, document layout, and other academicisms. The first thing they wanted was a simple, working system. And so far XML-RPC helps them with that.
So:
+: simplicity, brevity of messages, minimal check of data format,
-: lack of rigor, requires a separate description of the service.

REST

Probably Roy Fielding was the first to say “stop reinventing bicycles” and “everything is stolen before us” in relation to web services. Or maybe not the first, in any case, his words sounded the loudest. In his dissertation, Architectural Styles and the Design of Network-based Software Architectures, he described the basic principles of REST (Representational State Transfer) - a web services architecture that changed the developer's view by 180 degrees **. He said that “it is necessary to dance not from the corner, but from the stove” - in other words - it’s not the procedure that you need to call and pass the object to it, but to refer to the object. No need to turn the bike on a moped. After all, the HTTP protocol already has a number of methods for working with objects: GET (receive), POST (send / create), PUT (update), DELETE (delete).
Why engage in tautology and cause

POST /api/object.php?object_id=445&action=delete&user_id=255&auth_key=0Jf4tet5 HTTP / 1.1

When you can simply:

DELETE / objects / 445 HTTP / 1.1

Or another variant is practiced when POST is made to the resource itself, and delete is passed separately to the parameter:

POST / objects / 445 HTTP / 1.1

At the same time, if XML-RPC uses only the transport part from the HTTP protocol to transfer request / response XML, then REST uses HTTP in full: here are the authorization headers, content-negotiation — preferences in format, language, encoding and type response, various service headers, non-hemorrhoid binary data transfer, etc. Errors are well described by HTTP codes 4xx and 5xx. You can see that REST is an organic add-on over HTTP. This is not surprising because Roy is one of the developers of the HTTP protocol. In general, the more I deal with this protocol, the more it seems to me that it was 20 years ahead of its time, and the further the web develops, the more possibilities we use from it.
The message body itself can be transmitted in different formats: classic XML or geek JSON. In general, REST is not a protocol, it is an approach, and its flexibility is here, it seems to be telling us: “Guys, take the basic principles, and then do as you like.” Proximity to the HTTP protocol simplifies and speeds up its processing by web servers.
So:
+: flexibility, simplicity, processing speed (especially important for large sites), organic protocol, multi-format, compactness.
-: the lack of strict control of data, for practical reasons, you have to go beyond the ideal model.

SOAP

So we got to it - the protocol is a gift! But it was on him that I comprehended the dao of all web services and site api. I think everyone knows what the abbreviation SOAP - Simple Object Access Protocol means. That’s how the ideal protocol for web services should look like in Microsoft’s view. Let's look at what a typical query looks like:

Copy Source | Copy HTML<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ schemas.xmlsoap.org/soap/envelope"> <soapenv:Body> <req:echo xmlns:req="http://localhost:8080/axis2/services/MyService/"> <req:category>classifieds</req:category> </req:echo> </soapenv:Body> </soapenv:Envelope>

Copy Source | Copy HTML<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ schemas.xmlsoap.org/soap/envelope"> <soapenv:Header> <wsa:ReplyTo> <wsa:Address>schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address> </wsa:ReplyTo> <wsa:From> <wsa:Address>localhost:8080/axis2/services/MyService</wsa:Address> </wsa:From> <wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:MessageID> </soapenv:Header> <soapenv:Body> <req:echo xmlns:req="http://localhost:8080/axis2/services/MyService/"> <req:category>classifieds</req:category> </req:echo> </soapenv:Body> </soapenv:Envelope>

— ! — — , 10 ?
— — , , .

— XML Schema -? ? , «Simple»? — , — .

: SOAP . WSDL ( -), , - , SOAP , — soap («»). : rope («»).

- : « , : — . !».
: !

! - : . . - , , , . HTTP- , . , , ? .

API

API - — - ! , . , .
, ? , ? use/require/import/include/… . - ?
, , API.

1 API , . . , . , , ;-)

API. , — . , , ? — — , . — WSDL .

Copy Source | Copy HTML <pre> from ZSI.ServiceProxy import ServiceProxy # Zolera Soap Infrastructure api = ServiceProxy('http://webservices.aeroflot.ru/flightstatus.asmx?WSDL') # ... ! API . # api AirportInfo() Departure() AirportList() FlightInfo() Arrival() FlightSearch() # , . # : airport_list = api.AirportList() airport_list {'AirportListResult': {'Airport': [{'city': 'Colombo', 'code': 'CMB', 'id_country': 'SRI', 'name': 'Bandaranayake'}, {'city': 'Belfast', 'code': 'BFS', 'id_country': 'UK', 'name': 'Belfast Intl'}, ..... # . 2 API - . # , . # . # 15 : import datetime date1 = datetime.date(2009, 11, 15) arrival = api.Arrival(code='SVO', date=date1, order_field='airport', order='asc') arrival {'ArrivalResult': {'Flight': [{'airport': 'Adler/Sochi', 'calc': (1, 1, 1, 0, 0, 0, 0, 0, 0), 'company': 'SU', 'fact': (1, 1, 1, 0, 0, 0, 0, 0, 0), 'flight_no': '874', 'flt_pk': '2009101359805123', 'is_board': 0, 'is_check': 0, 'plan': (2009, 11, 15, 10, 55, 0, 0, 0, 0), 'real': (1, 1, 1, 0, 0, 0, 0, 0, 0), 'sched': (2009, 11, 15, 10, 55, 0, 0, 0, 0), 'status': ''}, ......
</pre>

-, XML, REST, , «» API?
«», :

— , .

API - , , .
API — , , . . - .

API .

, ?
, API , curl- , . .

API , — , . API, — . 10- — . .
, — — . .
, « — REST- ». — 5-10 , rest/xmlrpc/soap.

!

Source: https://habr.com/ru/post/75248/

All Articles