サービスはRESTfulですか？ WebサービスとRESTについて必要なこと/知っておくべきことすべて

はじめに

車輪を再発明するのは好きではないので、この記事は書きませんが、しなければなりませんでした。 RESTについてはすでに多くのことを述べています。 多くのWebサービスプロバイダーは、サービスがRESTfulであることを誓います。 インタビュー中に、バックエンド、モバイル、またはフロントエンドの開発者向けのインタビューであるかどうかに関係なく、RESTに関する少なくともいくつかの質問を間違いなく聞くことができます。 あるインタビューの中で、この質問をされたことが一度あります。「履歴書にRESTを知っていることを書いたので、 リソースがRESTfulサービスへのリクエストで見つからなかった場合、どのHTTPコードを受け取りますか？ 回答404が満場一致で採択されました。 正直なところ、この質問がRESTを知っているかどうかを理解するのにどのように役立つかはまだわかりませんでしたが、自信を持って言えることは1つです。 長い間私を悩ませてきたいくつかの質問があります：

1. なぜRESTはそんなに流行になったのですか？ このアーキテクチャは2000年に提案されましたか？
2. サービスがRESTfulである場合、何を受け取りますか？
3. サービスがRESTfulかどうかを判断する方法は？
4. RESTサービスURLをどのように正しく作成する必要がありますか？
5. RESTfulサービスで使用するhttpメソッドとコードは何ですか？

これらの質問の少なくとも1つに完全な答えを出すことができない場合は、読み続けてください。 これらのすべての質問に明確に回答できる場合は、正しいURLの形式を指定し、GET、POST、PUT、DELETEがリソースを使用するCRUD操作に対応している必要があることを考慮し、必ず読み続ける必要があります。



上記の質問に対する答えを見つけて全体像を示すために、インターネット、特にStack Overflowで多くの混乱があったことが判明したため、一連の仕様、Roy Fieldingの論文、およびLeonard Richardsonの本を読む必要がありました。 私が見つけた情報はかなり役立つように思えたので、私はそれをあなたと共有することにしました。



Webサービスの観点からRESTを検討しているため、この記事では、全体像を表すために知っておく必要のあるすべてのことを述べようとしました。



それでは、Webサービスの世界への旅を始めましょう。

SOAおよびWebサービス

サービス指向アーキテクチャとして拡張可能なSOAは、さまざまな所有領域で制御できる分散システムを編成および使用するためのパラダイムです[1]。 SOAでは、サービスは次の基準を満たす機能を指します[2]。

1. 特定の結果を持つ機能を表します。
2. 自己完結型です。
3. 顧客にとってはブラックボックスです。
4. 他のサービスで構成される場合があります。

サービスの説明 -これは、サービスとの対話に必要なサービスに関する情報です（WSDLなど）。

サービスプロバイダーは、 サービスを提供する人または組織です。

サービス消費者 -これらは顧客であり、サービスの消費者です。



定義[3]によると、 Webサービスは、ネットワークを介したマシン/プログラムの相互作用のために設計されたシステムです。 Webサービスには、マシン処理形式（サービスの説明）で記述されたインターフェイスが必要です。 他のシステムは、メッセージを介してWebサービスと対話する必要があります。



WebサービスとSOAの関係は、Webサービスを通じてSOAを実装できるということです。



SOAを実装するために他に存在する、または存在する方法に興味がある場合は、COMおよびCORBAをご覧ください。

Webサービスプロトコル

どのサービスがRESTfulで、どのサービスがRESTfulではないかを決定する前に、いくつかの実装、またはWebサービスプロトコルと呼ばれる方法を検討してください。 有名なWebサービスプロトコルのリストは[4]にあります。



1. XML-RPC



XML-RPC（XMLリモートプロシージャコール）プロトコル[5]は、1999年に最初に公開されました。 XML-RPCメッセージ全体がHTTP-POSTリクエストです。 XMLはメッセージのエンコードに使用されます。 プロシージャパラメータには、スカラー値、数値、文字列、日付、配列、構造を使用できます。 Webサービスの応答には、プロシージャから返された値、またはコードとエラーメッセージを格納できます。





XML-RPCプロトコルの短所として、大きなメッセージサイズ（通常のXMLの4倍）およびWebサービス記述言語（WSDLに似たもの）の欠如があり、これを使用してプロキシクラスを生成できます。クライアント側。



2. JSON-RPC



2009年に公開されたJSON-RPCプロトコル[6]は、その動作原理がXML-RPCに非常に似ています。 主な違いは、データのエンコード方法、トランスポート層からの独立性、通知（通知要求）の送信機能、および複数の要求を同時に送信する際の応答の識別機能です。



JSON-RPCはJSONを使用してデータをエンコードします。 プロシージャとパラメータの名前に加えて、リクエストはid値も示します。これは、クライアント側でレスポンスを識別するために使用されます。 つまり、id = 12345のリクエストを送信した場合、このリクエストのレスポンスはid = 12345のメッセージを返す必要があります。



通知-これらは、サーバーが応答しない可能性がある特別な要求です。 リクエストを通知としてマークするには、idパラメーター値= nullを指定します。



トランスポート層からの独立は、JSON-RPC [6]仕様がHTTPを必須プロトコルとして指定していないという事実によってのみ引き起こされます。 HTTPでJSON-RPCを使用する場合、POST要求を使用する必要があります。





XML-RPCの場合のように、JSON-RPCの欠点は、Webサービス記述言語の欠如です（WSDLに似ています）。



3. SOAP



Simple Object Access Protocol（SOAP）[7]はXML-RPCの後継です。 SOAPの主な機能は次のとおりです。

1. 送信されるすべてのメッセージは、XML（SOAPメッセージ）を使用してエンコードされます。
2. すべてのSOAPサービスには、XMLでもあるWSDLの説明があります。 これにより、クライアントはプロキシクラスを自動的に生成できます。
3. SOAPは、ほぼすべての既知のTCP / IPプロトコル（TCP、UDP、HTTP、SMTP、FTPなど）をサポートします。 このため、SOAPは以前のプロトコルに比べてかなり複雑なプロトコルです。
4. HTTPを使用する場合、GETメソッドとPOSTメソッドの両方がサポートされます。 GETは、データの受信にのみ使用できます。 サーバー側では、何も変更しないでください。 POSTはあらゆる場面で使用できます。 実際には、通常POSTのみが使用されます。

SOAPの主な欠点は、柔軟性による複雑さです。 もう1つの重要な欠点は、XMLのみでのコーディングのサポートです。

REST

RESTはおそらく最も人気のあるWebサービスプロトコルです 。



実際、RESTはまったくプロトコルではなく、まったく新しいものでもありません。 RESTは、2000年代にRoy Fieldingの論文「Archtectural Styles and the Design of Network-based Software Architectures」[8]で提案されたアーキテクチャです。 これに先立ち、RESTアーキテクチャはIETFおよびW3C内の多くのプロジェクトで使用されていました。 論文自体では、「Webサービス」またはSOAという用語を見つけることができません。 RESTアーキテクチャは、分散ハイパーメディアシステムの正しい設計、つまり、現在のワールドワイドウェブと呼ばれるもののために提案されています。 フィールディングの論文を真剣に受け止めるために、ロイはHTTP 1.1のアーキテクトであり、HTTPとURIのインターネット標準の共著者であると言います[10]。 一般的に、男は真面目で有名です。



RESTアーキテクチャーに従って分散システムを設計するには、次の基準を満たしている必要があります。

1. クライアントサーバー システムはクライアントとサーバーに分割する必要があります。
2. ステートレス。 サーバーはクライアント情報を保存しないでください。 リクエストには、リクエストの処理に必要なすべての情報と、必要に応じて顧客IDを保存する必要があります。
3. キャッシュ。 キャッシュ可能なかどうかにかかわらず、各回答にマークを付ける必要があります。
4. 統一インターフェース。 システムコンポーネント間のユニバーサルインターフェイス。
   
   
   
   ユニバーサルインターフェイスを取得するには、次の制限が導入されます。
   
   
   
   
   • リソースの識別。
     
     
     
     RESTでは、名前を付けることができるのはリソースだけです。 たとえば、ユーザー、HTMLドキュメント、画像、登録ユーザー、赤いTシャツ、空腹の犬、現在の天気など。 RESTの各リソースは、リソースの状態が変わっても変わらない安定した識別子によって識別される必要があります。 この場合、RESTの識別子はURIです。
     
     
     
     
   • 表現によるリソースの操作。
     
     
     
     RESTのビューは、リソースに対してアクションを実行するために使用されます。 リソースビューは、リソースの現在の状態または望ましい状態です。 たとえば、リソースがユーザーである場合、プレゼンテーションはそのユーザーのXMLまたはHTML記述である場合があります。
     
     
     
     
   • 自己記述的なメッセージ。
     
     
     
     自己記述的とは、要求と応答が処理に必要なすべての情報をそれ自体に保存する必要があることを意味します。 単一のリクエストを処理するための追加のメッセージやキャッシュがあってはなりません。
     
     
     
     
   • HATEOAS（アプリケーション状態のエンジンとしてのハイパーメディア）。
     
     
     
     この段落は、ハイパーテキストを使用してAPIをナビゲートする必要があることを意味します[9]。 SOAの場合、これにはサービスの説明が使用されることに注意してください。
     
     
     
     この項目をさらに詳しく検討してください。
     
     
     
     
     以下の例では、残高のリクエストを受信すると、レスポンスは残高だけでなく、アカウントで実行できるアクションも示します。

      GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">100.00</balance> <link rel="deposit" href="/account/12345/deposit" /> <link rel="withdraw" href="/account/12345/withdraw" /> <link rel="transfer" href="/account/12345/transfer" /> <link rel="close" href="/account/12345/close" /> </account>
           
           
     
             
             
             
           
     
         
             
             
             
           
           
     
             
             
             
           
     
         
          

     
     
     
     
     
     
     負のバランスで同じ例を考えてみましょう：

      GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">-25.00</balance> <link rel="deposit" href="/account/12345/deposit" /> </account>
           
           
     
             
             
             
           
     
         
             
             
             
           
           
     
             
             
             
           
     
         
          

     
     
     
     
     
     ご覧のとおり、このアカウントではこれらのアクションを使用できないため、レスポンスにはデポジットと送金への参照が含まれなくなりました。
   
   
   
5. 階層化システム。 RESTでは、システムをレイヤーの階層に分割できますが、各コンポーネントは次のレイヤーのコンポーネントのみを表示できるという条件があります。 たとえば、PayPalサービスを呼び出し、次に彼がVisaサービスを呼び出す場合、Visaサービスを呼び出すことについて何も知らないでください。
   
   
   
   
6. コードオンデマンド。 RESTを使用すると、クライアント側でコードまたはプログラムを読み込んで実行できます。

したがって、分散システムがリストされている6つのポイントすべてを満たしている場合、それはRESTアーキテクチャに基づいていると言えます。この場合、このようなWebサービスはRESTfulサービスと呼ばれます。



これらの段落ですでに気づいたように、GET、PUT、POST、DELETEリクエスト、JSONエンコーディング、HTTPなどについては何も言われていません。



RESTは単なるアーキテクチャであり、どのプロトコルにも関連付けられていません。



確かに、RESTアーキテクチャには驚くべきものや新しいものはないことにすでに気付いています。 Webの開発が始まったばかりの2000年にRESTで新しく追加されました。 RESTとその関連性をよりよく理解するには、Webが各サイトがハイパーテキストである分散ハイパーメディアシステムであると想像してください。



それからもちろん疑問が生じます-実際に私たちが見たり、していることは何ですか？ インターネットでは、RESTfulサービスがどのように見えるべきか、どのように見えるべきでないかについて多くの論争を見つけることができます。 使用するHTTPメソッドと使用しないHTTPメソッド。 一般に、すでに明らかなように、RESTfulサービスに関する仕様は存在しないため、これらすべての議論には理論的根拠はありません。 あるプロジェクトでは、POSTを使用して新しいレコードを作成し、別のプロジェクトでは更新に使用し、3番目では削除に使用することを決定できます。 これらのソリューションは、RESTアーキテクチャに決して関連付けられていません。

REST＆Richardson成熟度モデル

それでは、RESTはWebサービスにどのように関連していますか？ RESTfulとみなせるサービスとそうでないサービス サービスがすべてのフィールディングポイントを満たす場合、何を受け取りますか？ これらの質問に順番に答えます。

1. RESTアーキテクチャーは、Webの実践において過去16年にわたって実証されています。 WebサービスはWebの一部であるため、多くの企業/開発者/研究者は、Webサービスの場合にRESTアーキテクチャを使用することを決定しました。これにより、コンポーネントのスケーラビリティが向上し、セキュリティが確保され、独立した展開などが行われます
   
   
   
   
2. WebサービスがFieldingのすべての基準を満たしている場合、HTTP DELETEメソッドを使用してレコードを削除するかどうかに関係なく、RESTfulと見なすことができます。 これをWebに追加します。一般的に使用されるメソッドはGETとPOSTであり、WebサービスがWebにできるだけ似ている必要がある場合、PUTとDELETEを使用することも何らかの形で正しくありません。
   
   
   
   
3. フィールディングはウェブと分散ハイパーテキストシステムについて書いていますが、彼の論文の一部をコピーします。 英語では、これはより説得力があります。
   
   

   RESTは一連のアーキテクチャ上の制約を提供し、全体として適用すると、コンポーネントの相互作用のスケーラビリティ、インターフェイスの一般性、コンポーネントの独立した展開、および中間コンポーネントを強調して、相互作用の待ち時間を短縮し、セキュリティを強化し、
   
   レガシーシステムをカプセル化します。

もちろん、すべてが非常にクールに聞こえますが、WebサービスをRESTに従って設計する必要がありますか、それとも単なるトレンドですか？ レナードリチャードソンのRMM（リチャードソン成熟度モデル）を見てみましょう。



数百のWebサービス[11]を分析した後、RMMモデルが提案され、Webサービスの成熟度の品質、またはRichardsonがそれを呼んだように評価しました。 RMMモデルは4つのレベルで構成されています。 サービスが最後のレベルに対応している場合は、RESTfulと見なすことができます。 以下に、著者によるとアーロン・シュワルツ、レナード・リチャードソン、および他の有名な人々によってチェックされた[12]の例と数字を示します。 すべての例は、次のストーリーに基づいています。医師と予約を取りたいです。 Webサービスから、特定の日付の無料の受付時間を取得してから、予約をする必要があります。 したがって、この例では、これら4つのレベルすべてを検討します。

レベル0：1つのURI、1つのHTTPメソッド。

ここで、HTTPは分散システムコンポーネントの相互作用にのみ使用されます。 POSTなど、1つのメソッドのみが使用されます。 ご想像のとおり、このようなWebサービスはXML-RPCおよびSOAPプロトコルです。











ここではXMLは例としてのみ使用され、代わりにJSON、HTMLなどを使用できます。 Webサービスには、1つのURL（相対URL）のみがあります：/ pointmentService。 要求された機能は、要求本文に示されています。



サービスがレベル​​0に対応する場合、彼はまだ子供です。



次に、レベル1のWebサービスを操作するときの同じ例を見てみましょう。

レベル1：複数のURI、1つのHTTPメソッド。

このレベルのサービスは、「分割して征服する」という概念を使用しています。 リソースの概念はサービスに導入され、このリソースのURLは特定のリソースを操作するために使用されます。











そのため、医師と何らかのアクションを実行する場合は、相対URL /医師を使用する必要があり、アクションが訪問に関連付けられている場合はURL /スロットを使用する必要があります。 最初のレベルのサービスとゼロレベルのサービスを比較すると、後者の場合、リソースは1つだけであり、このリソースはWebサービスそのものです。



サービスがレベル​​1の場合、彼はティーンエイジャーです。

レベル2：複数のURI。それぞれ異なるHTTPメソッドをサポートしています（HTTPの適切な使用）。

したがって、レベル1では、Webサービスのすべてのメソッドはリソースを使用して分離されましたが、リソースを使用して一連のアクションを実行できます。 これらのアクションも何らかの形で論理的に分離されるように、異なるメソッド（GET、HEAD、POST、PUT、DELETE、TRACE、CONECT）で操作を送受信するHTTP機能が使用されます。 たとえば、メソッドが読み取りの場合、POSTまたはPUT UTを作成する場合はGETを使用できます 原則的には可能であり、その逆も可能ですが、これらのメソッドにはHTTPにいくつかの概念と特性があるため、これらの概念はWebサービスと同じである方が良いです。そうでなければ、リソースを作成するためのキャッシュされたメソッドを取得できます。 言い換えれば、どの操作にどのメソッドを使用するかは、HTTPプロトコルの正しい使用法についてはすでに疑問です。







おそらく例のための時が来ました：







さまざまなHTTPメソッドの導入に伴い、正しいHTTPステータスコードを返す必要性も導入されています。 たとえば、会議を作成するリクエストの場合、作成された場合はコード201が返され、アクション中に選択された日時にすでに登録されている場合は、409の競合コードが返されます。 繰り返しますが、ポイントはHTTPプロトコルの適切な使用です。



サービスがレベル​​2に対応している場合、それはすでに成人男性です。

レベル3：HATEOAS。 リソース自体は、その機能と関係を説明しています。

HATEOAS（アプリケーション状態のエンジンとしてのハイパーテキスト）、私の意見ではハイパーメディアに必須の要件ですが、これがWebサービスにどの程度関連しているかはわかりません。 それでも、HATEOASは、関心のあるリソースで実行できるURLの形式でアクションを返すWebサービスの特性です。







HATEOASについては既に上記で説明したので、ここでは例を示します。





空き時間ごとにアクションを実行するURLがあります。この場合、この時間の登録です。





HATEOASの利点は、Webサービス開発者がクライアントとは無関係にURIを変更できることです。 さらに、Webサービス自体は、WSDLなしで自身を記述します。 HATEOASを正しく表現するには、静的なページからWebサイトを想像してください。 メインページを開くと、すでに他のすべてへのリンクがあります。 Webサイトに移動してそこで何かを見つけるために、このWebサイトでAPIドキュメントのようなドキュメントを読む必要はありません。 繰り返しますが、HATEOASをサポートするWebサービスの必要性についての私の主観的な意見はかなり悲観的です。



サービスがレベル​​3に対応している場合、サービスはすでにRESTfulと呼ばれ、もちろん、経験豊富な老人と呼ばれます。

おわりに

これらの行を読んだ場合は、記事全体を読んで結論に達したか、時間がないためにメインの記事をめくって結論だけを読んだかのどちらかです。



2番目のケースは最初のケースよりも一般的であるため、基本的な概念を示します。

1. Webサービスは、SOAアーキテクチャを実装する方法の1つです。
2. Webサービスプロトコルは、Webサービスの特定の実装です（XML-RPC、SOAP、JSON-RPCなど）。
3. RESTは、2000年に提案されたアーキテクチャであり、一般的にWebコンポーネントと分散ハイパーメディアシステムを適切に作成するために使用されました。
4. SOAPとRESTの違いの問題は、バイソンと捕食者の違いを尋ねることとほぼ同じです。 SOAPは仕様を持つプロトコルであり、RESTはHTTPおよびURLを使用してWebサービスを作成するために使用できるアーキテクチャです。
5. Richardson Maturity Modelは、Leonard RichardsonがWebサービスの成熟度を評価するために提案したモデルです。 «», «», «» «» , RMM.

– . , , RMM, HATEOAS. «» «» . - amazon, , , «». , «», , ( ).

文学

1. www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

2. www.opengroup.org/standards/soa

3. www.w3.org/TR/ws-arch/#whatis

4. en.wikipedia.org/wiki/List_of_web_service_protocols

5. xmlrpc.scripting.com/spec.html

6. www.jsonrpc.org/specification

7. www.w3.org/TR/soap

8. www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

9. restcookbook.com/Basics/hateoas

10. roy.gbiv.com/untangled/about

11. www.crummy.com/writing/speaking/2008-QCon/act3.html

12. martinfowler.com/articles/richardsonMaturityModel.html