悲しいかな、Habrakatの背後にある現実は私を大いに失望させました-私は別の自転車、さらには四角い車輪を見ました。 (同僚、個人的なことは何もありません、技術的な議論です。)確かに、著者は正直に言って、いくつかのサイトでRESTというファッションの言葉を見て、それをすることに決めました。 今や彼らは、この「REST」を独自の方法で理解しました。おおよそ、祖父シューカーが説明辞書を読んで理解した方法です。
このトピックでは、サイトAPIで自転車を本当に終わらせることをお勧めします。 結局のところ、それは冗談です:APIはサイトへのアクセスと外部システムの接続を簡単にするために開発されていますが、それなしではなくそれでさらに難しいことがわかります:)
カットを少し下げて、ユニバーサルAPIのすべての自転車の死刑に署名します。 根拠にならないように、すべてを例で説明します。
しかし、すぐに警告する必要があります-記事を読んだ後、ギャグ反射なしで「ユニバーサルサイトAPI」という誇りのある名前で次のVasya Pupkinの自転車を見ることができません。
次の質問は、物語で検討されます。
したがって、今日、サイトAPIにアクセスする最も一般的な方法は次のとおりです。
1. XML-RPC。
2. REST(これはプロトコルではなく、アプローチであるという条件付き)。
3. SOAP。
基本技術と比較
XML-RPC
XML-RPCがこのすべてのナンセンスの先駆者であると言っても、私はあまり間違えていないと思います。今では「Webサービス」と「サイトAPI」という大きな言葉を呼んでいます。 1998年にMicrosoftの注文により開発されました。 核となるのは、XMLのメッセージフォーマットを使用した古き良きRPCの生まれ変わりです。 このプロトコルの疑いのない利点は、そのシンプルさであり、その結果、実装が容易です。
典型的なXML-RPCリクエストの例を次に示します。
<?xml version = "1.0"?> <methodCall> <methodName> examples.getAirportCode </ methodName> <params> <param> <value> <i4> 567 </ i4> </ value> </ param> </ params> </ methodCall>
同じ簡単な答えを得ることができるもの:
<?xml version = "1.0"?> <methodResponse> <params> <param> <value> <string> SVO </ string> </ value> </ param> </ params> </ methodResponse>
エラーメッセージはほとんど同じように見えます。 このような答えは、車はもちろんのこと、人にとっても簡単に解析できます。 そのような単純さは、2つの方法で彼に貢献しました。一方で、彼は顧客に受け入れられず、標準になりませんでした。もう一方で、彼は単純で紛れもないプログラマーの群衆が好きでした。 これらの人々は、システム間で情報を交換するためのシンプルで信頼できる手段を必要としていました。彼らは、美しいURL、ドキュメントスキーム、その他のアカデミーのようなくだらないことに煩わされたくありませんでした。 彼らが最初に望んだのは、シンプルな作業システムでした。 そしてこれまでのところ、XML-RPCはそれらを支援してきました。
だから:
+:シンプルさ、メッセージの簡潔さ、データ形式の最小限の検証、
-:厳密さが不十分な場合、サービスの個別の説明が必要です。
REST
ロイ・フィールディングは、おそらくウェブサービスに関して「自転車の発明をやめろ」と「私たちからすでにすべてが盗まれた」と言った最初の人物だったでしょう。 そして、最初の言葉ではないかもしれませんが、いずれにしても、彼の言葉は最も大きな音でした。 彼の論文、Architectural Styles、およびNetwork-based Software Architecturesの設計では、REST(Representational State Transfer)の基本原則について説明しました。これは、開発者の意見を180度変更したWebサービスアーキテクチャです**。 彼は、「角から踊る必要はなく、ストーブから踊る必要がある」、つまり、プロシージャを呼び出してオブジェクトを転送する必要はなく、オブジェクトにアクセスする必要があると言いました。 モペットにバイクを巻き付ける必要はありません。 実際、HTTPプロトコル自体には、オブジェクトを操作するための多くのメソッド(GET(受信)、POST(送信/作成)、PUT(更新)、DELETE(削除))が既にあります。
なぜトートロジーと電話
POST /api/object.php?object_id=445&action=delete&user_id=255&auth_key=0Jf4tet5 HTTP / 1.1
簡単にできるとき:
DELETE /オブジェクト/ 445 HTTP / 1.1
または、リソース自体に対してPOSTが行われ、パラメーターによって削除が個別に渡される場合、オプションは引き続き実行されます。
POST /オブジェクト/ 445 HTTP / 1.1
同時に、XML-RPCがHTTPプロトコルからのトランスポート部分のみを使用して要求/応答XMLを送信する場合、RESTは完全にHTTPを使用します。認証ヘッダー、コンテンツネゴシエーション-形式、言語、エンコード、およびタイプの設定があります応答、さまざまなサービスヘッダー、出血のないバイナリデータの送信など。 エラーは、HTTPコード4xxおよび5xxで詳しく説明されています。 RESTはHTTPを介したオーガニックアドオンであることがわかります。 RoyはHTTPプロトコルの開発者の1人であるため、これは驚くことではありません。 一般に、このプロトコルを理解すればするほど、そのプロトコルはその20年先を進んでいるように見え、Webが発展すればするほど、より多くの機会が利用されます。
メッセージ本文自体は、さまざまな形式(従来のXMLまたはギークJSON)で送信できます。 一般的に、RESTはプロトコルではなく、アプローチであり、ここでその柔軟性が結論付けられました。それはある種のことです。「みんな、基本原則を守って、好きなようにやってください」 HTTPプロトコルに近接しているため、Webサーバーによる処理が簡素化および高速化されます。
だから:
+:柔軟性、シンプルさ、処理速度(特に大規模なサイトで重要)、有機プロトコル、マルチフォーマット、コンパクト。
-:厳密なデータ管理の欠如;実際的な理由から、理想的なモデルを超えなければなりません。
SOAP
それで私たちは彼に着きました-プロトコルギフト! しかし、すべてのWebサービスとWebサイトAPIのタオに気付いたのはその上でした。 SOAPの略語-Simple Object Access Protocolを誰もが知っていると思います。 これが、MicrosoftがWebサービスに最適なプロトコルのように見える方法です。 典型的なクエリがどのように見えるか見てみましょう:
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 , curl- , . .
API , — , . API, — . 10- — . .
, — — . .
, « — REST- ». — 5-10 , rest/xmlrpc/soap.
!