RESTサービス紹介
4455 ワード
REST発生背景
WebサービスとWCFはHTTPプロトコルを使用していますが、実はSOAP上に確立されています。したがって、WebサービスというとSOAPを思い付きます。つまり、HTTP上に直接に確立されておらず、HTTPを挟み込みの他のアプリケーションプロトコルとして使うだけで、ファイアウォールを越える方法は、HTTPプロトコルを十分に掘り起こして利用していないと言えます。HTTPプロトコルでは、これらのリソースの表現におけるメッセージの転送と動作によって、いくつかのリソースの動作が実行され、ウェブアーキテクチャの意味が反映されるので、この非常に簡単なインターフェースを使用して、幅広い機能を得ることが可能である。表現化状態移行（Representational State Transfer、略してREST）はRoy Thomas Fielding博士が2000年に彼の論文で提出したソフトウェアアーキテクチャのスタイルである。RESTソフトウェアアーキテクチャのスタイルは急速に今の世界で最も成功したインターネットの超メディア分散システムになっています。これは私たちのネットワークプロトコルHTTPの本来の姿を本当に理解させます。インターネットサービスの主流技術になっています。RESTソフトウェアアーキテクチャは抽象的な概念であり、このインターネットを実現するための超メディア分散システムの行動指針である。いかなる技術を利用してもこのような理念を実現できる。このソフトウェアアーキテクチャを実現する一番有名なのはHTTPプロトコルです。私たちはRESTもREST/HTTPとして書いていますが、実際にはRESTをHTTPに基づくRESTソフトウェアアーキテクチャとして理解しています。利点：SOAPベースのWeb Serviceは技術と関連コードを実現し、より成熟しており、安全性が良いが、使用しきい値が高く、大合併の場合は性能問題があるかもしれない。現在、3つの主流のWebサービス実施形態では、RESTモードは複雑なSOAPおよびXML-RPCに比べてより簡潔であるため、多くのWebサービスはRESTスタイルの設計と実装を開始する。
RESTとは
表現状態移行：REST（Representational State Transfer）は、Webサービスの標準的なHTTP方法（GET/PUT/POST/DELETE）を採用して、すべてのWebシステムのサービス能力を抽象化しており、これはソフトウェアアーキテクチャスタイルであり、ネットワークアプリケーションに対する開発方式であり、開発の複雑さを低減することができる。RESTはリソースの観点からネットワーク全体を観察し、各所に分布しているリソースはURIによって決定され、クライアントのアプリケーションはURIによってリソースの特性評価を取得する。
RESTの具体的な技術実現：Asp.Net WebAPI
REST二つの基本概念
1.資源（Resource）：情報を資源として抽象化し、名前付きの情報（データと機能を含む）を一つの資源、一枚の写真、一つの他の資源の集合などとすることができます。RESTでは、リソースは状態と呼ばれています。時間の変化に従うからです。2.表現（Representation）：RESTはURIによってリソースの表現を取得し、リソースに対して動作を実行し、コンポーネント間でこの表現を伝達する。
どのような表現化状態転移ですか？RESTの中で、資源は状態で、インターネットは巨大な状態機です。各ページはその状態です。Urlは状態の表現である。RESTアプリケーションは、ハイパーリンクをクリックすることにより、状態から次の状態に遷移する状態遷移プロセスを転送といいます。
例えば、Bing検索結果のページ別リストでは、urlは以下の通りである。http://www.bing.cn/search?q=REST&hl=zh-CN&newwindow=1&start=0&sa=N
第二ページ:http://www.bing.cn/search?q=REST&hl=zh-CN&newwindow=1&start=10&sa=N
Bingでは、検索結果の各ページを資源（状態）とし、urlで表し、同じ検索キーワードの異なるページをstartパラメータで区別します。最初のページから2ページ目のリンクをクリックすると、次の状態にジャンプします。
RESTスタイルアーキテクチャの主な制約条件
クライアントサーバ：懸念点を分離し、ユーザーインターフェース（ユーザーインターフェースなど）とデータを分離し、インターフェースが変わらないなら、コンポーネントは独立して進化することができます。
無状態：クライアントチャネルサーバからの各要求は、要求を理解するために必要なすべての情報を含む必要があり、サーバ上に記憶されているコンテキストを利用することができない。システムの拡張可能性を向上させ、3つの利点がある。監視システムは、要求の性質を決定するために、要求以外の複数の要求を確認する必要がない。信頼性は、局所的な障害から回復するタスク量を軽減し、迅速に位置決めできる。伸縮性は、複数の要求の間に状態を保存する必要がなく、サーバが速やかにリソースを解放することができ、サーバがリソースの管理を要求する必要がない。欠点は、サーバ上の共有コンテキストに状態を保存できないため、要求中に送信された重複データが増加し、ネットワーク性能が低下するため、制約が三つあることである。
キャッシュ：要求応答中のデータ表示または暗黙的なマークはキャッシュ可能またはキャッシュ不可能です。キャッシュは、後の同じ要求のためにこの応答のデータを再利用することができる。しかし、キャッシュ管理がうまくいかないと、信頼性が低下し、キャッシュ中の古いデータと直接サーバにアクセスして得られたデータとの差が大きいです。
統一インターフェース：コンポーネント間には統一インターフェースが必要で、RESTスタイルアーキテクチャが他のスタイルアーキテクチャを区別する核心的特徴である。RESTは4つのインターフェースによって制約されて定義されています。リソースの識別、Web-BasedシステムのリソースはURIによって表されています。データベース記憶システムのリソースはXML、JSONなどであります。リソースに対して実行される動作を表すことによって、表現にはこのリソースを操作する情報が含まれ、例えば、添削チェック、HTTPプロトコルのGET、POST、PUT、DELETE方法にマッピングされる。説明されたメッセージから：メッセージには、どのWebAPI／Sevletによって処理されるべきかなどの情報が含まれ、応答にはキャッシュされてもよいかどうかなどの情報が含まれている。アプリケーションエンジンとしての超メディア。
REST基本設計原則
原則1：HTTPの方法を使ってリソースアクセスを行い、HTTP POST方法を使ってリソースを作成し、GET方法を使ってリソースを読み取り、PUT方法を使ってリソースを更新し、DELETE方法を使ってリソースを削除する。
原則二：無状態／無セッションのサービス設計を使用して、長い間、人々は状態のあるサービス設計を採用して、クライアントとサービスの間の複数回のインタラクションの中で一定の文脈を維持する。しかし、ある状態の設計により、作業負荷の増加に伴ってプログラムが伸縮しにくくなりました。例えば、あるサービス・インスタンスが10000セッションの状態を持っていると、通常、サービス・インスタンスを増加することによって、その作業負荷を分担することは困難である。作業負荷がロックされている。逆に、プログラムが無状態に設計されているなら、サービスの実例を自由に増加させ、これらの例の間で負荷をバランスさせて、サービスがより良い伸縮性を持つようにすることができます。これは大規模な分散システムにおいて特に重要です。
リソースをはっきりとしたURLパスで表すと、クライアントがリソースをより理解しやすく操作することができる。URLは自己解釈のインターフェースとして見られ、説明を多くする必要がなく、そのURLがどのようなリソースを指しているのか、またどのように関連するリソースを獲得しているのかが分かります。
原則4：XMLまたはJSONを使用してデータサービスと要求を送信するメッセージデータには、リソースの属性についての記述が含まれており、サービスは構造が良く、読み取りが容易な方法でリソースを記述すべきである。XML、JSONは構造の良い言語で、読書に適しています。JSONはXMLよりもっと簡潔です。
RESTセキュリティ
REST/HTTPネットワークサービスが直接クライアントの前に露出して、サービスの安全を確保するにはどうすればいいですか？
REST/HTTPネットワークサービスの情報パッケージはファイアウォールによって理解され制御されます。操作とリンクに従って情報パッケージをフィルタリングしてもいいです。外部から来たのは自分のサーバーのリソースしか読み取れません。これは、システム管理者にとってソフトウェア管理をより簡単にする。
二：RESTのセキュリティは、伝送安全プロトコルSSL/TLS、HTTP基本認証と要約認証を利用することもできる。
三：情報ベースのWeb Services Securityをセキュリティ認証の補完案として利用することもできる。
第三者オープンソースのOpenIDとOauthライブラリを安全認証方式の選択とします。
WebサービスとWCFはHTTPプロトコルを使用していますが、実はSOAP上に確立されています。したがって、WebサービスというとSOAPを思い付きます。つまり、HTTP上に直接に確立されておらず、HTTPを挟み込みの他のアプリケーションプロトコルとして使うだけで、ファイアウォールを越える方法は、HTTPプロトコルを十分に掘り起こして利用していないと言えます。HTTPプロトコルでは、これらのリソースの表現におけるメッセージの転送と動作によって、いくつかのリソースの動作が実行され、ウェブアーキテクチャの意味が反映されるので、この非常に簡単なインターフェースを使用して、幅広い機能を得ることが可能である。表現化状態移行（Representational State Transfer、略してREST）はRoy Thomas Fielding博士が2000年に彼の論文で提出したソフトウェアアーキテクチャのスタイルである。RESTソフトウェアアーキテクチャのスタイルは急速に今の世界で最も成功したインターネットの超メディア分散システムになっています。これは私たちのネットワークプロトコルHTTPの本来の姿を本当に理解させます。インターネットサービスの主流技術になっています。RESTソフトウェアアーキテクチャは抽象的な概念であり、このインターネットを実現するための超メディア分散システムの行動指針である。いかなる技術を利用してもこのような理念を実現できる。このソフトウェアアーキテクチャを実現する一番有名なのはHTTPプロトコルです。私たちはRESTもREST/HTTPとして書いていますが、実際にはRESTをHTTPに基づくRESTソフトウェアアーキテクチャとして理解しています。利点：SOAPベースのWeb Serviceは技術と関連コードを実現し、より成熟しており、安全性が良いが、使用しきい値が高く、大合併の場合は性能問題があるかもしれない。現在、3つの主流のWebサービス実施形態では、RESTモードは複雑なSOAPおよびXML-RPCに比べてより簡潔であるため、多くのWebサービスはRESTスタイルの設計と実装を開始する。
RESTとは
表現状態移行：REST（Representational State Transfer）は、Webサービスの標準的なHTTP方法（GET/PUT/POST/DELETE）を採用して、すべてのWebシステムのサービス能力を抽象化しており、これはソフトウェアアーキテクチャスタイルであり、ネットワークアプリケーションに対する開発方式であり、開発の複雑さを低減することができる。RESTはリソースの観点からネットワーク全体を観察し、各所に分布しているリソースはURIによって決定され、クライアントのアプリケーションはURIによってリソースの特性評価を取得する。
RESTの具体的な技術実現：Asp.Net WebAPI
REST二つの基本概念
1.資源（Resource）：情報を資源として抽象化し、名前付きの情報（データと機能を含む）を一つの資源、一枚の写真、一つの他の資源の集合などとすることができます。RESTでは、リソースは状態と呼ばれています。時間の変化に従うからです。2.表現（Representation）：RESTはURIによってリソースの表現を取得し、リソースに対して動作を実行し、コンポーネント間でこの表現を伝達する。
どのような表現化状態転移ですか？RESTの中で、資源は状態で、インターネットは巨大な状態機です。各ページはその状態です。Urlは状態の表現である。RESTアプリケーションは、ハイパーリンクをクリックすることにより、状態から次の状態に遷移する状態遷移プロセスを転送といいます。
例えば、Bing検索結果のページ別リストでは、urlは以下の通りである。http://www.bing.cn/search?q=REST&hl=zh-CN&newwindow=1&start=0&sa=N
第二ページ:http://www.bing.cn/search?q=REST&hl=zh-CN&newwindow=1&start=10&sa=N
Bingでは、検索結果の各ページを資源（状態）とし、urlで表し、同じ検索キーワードの異なるページをstartパラメータで区別します。最初のページから2ページ目のリンクをクリックすると、次の状態にジャンプします。
RESTスタイルアーキテクチャの主な制約条件
クライアントサーバ：懸念点を分離し、ユーザーインターフェース（ユーザーインターフェースなど）とデータを分離し、インターフェースが変わらないなら、コンポーネントは独立して進化することができます。
無状態：クライアントチャネルサーバからの各要求は、要求を理解するために必要なすべての情報を含む必要があり、サーバ上に記憶されているコンテキストを利用することができない。システムの拡張可能性を向上させ、3つの利点がある。監視システムは、要求の性質を決定するために、要求以外の複数の要求を確認する必要がない。信頼性は、局所的な障害から回復するタスク量を軽減し、迅速に位置決めできる。伸縮性は、複数の要求の間に状態を保存する必要がなく、サーバが速やかにリソースを解放することができ、サーバがリソースの管理を要求する必要がない。欠点は、サーバ上の共有コンテキストに状態を保存できないため、要求中に送信された重複データが増加し、ネットワーク性能が低下するため、制約が三つあることである。
キャッシュ：要求応答中のデータ表示または暗黙的なマークはキャッシュ可能またはキャッシュ不可能です。キャッシュは、後の同じ要求のためにこの応答のデータを再利用することができる。しかし、キャッシュ管理がうまくいかないと、信頼性が低下し、キャッシュ中の古いデータと直接サーバにアクセスして得られたデータとの差が大きいです。
統一インターフェース：コンポーネント間には統一インターフェースが必要で、RESTスタイルアーキテクチャが他のスタイルアーキテクチャを区別する核心的特徴である。RESTは4つのインターフェースによって制約されて定義されています。リソースの識別、Web-BasedシステムのリソースはURIによって表されています。データベース記憶システムのリソースはXML、JSONなどであります。リソースに対して実行される動作を表すことによって、表現にはこのリソースを操作する情報が含まれ、例えば、添削チェック、HTTPプロトコルのGET、POST、PUT、DELETE方法にマッピングされる。説明されたメッセージから：メッセージには、どのWebAPI／Sevletによって処理されるべきかなどの情報が含まれ、応答にはキャッシュされてもよいかどうかなどの情報が含まれている。アプリケーションエンジンとしての超メディア。
REST基本設計原則
原則1：HTTPの方法を使ってリソースアクセスを行い、HTTP POST方法を使ってリソースを作成し、GET方法を使ってリソースを読み取り、PUT方法を使ってリソースを更新し、DELETE方法を使ってリソースを削除する。
原則二：無状態／無セッションのサービス設計を使用して、長い間、人々は状態のあるサービス設計を採用して、クライアントとサービスの間の複数回のインタラクションの中で一定の文脈を維持する。しかし、ある状態の設計により、作業負荷の増加に伴ってプログラムが伸縮しにくくなりました。例えば、あるサービス・インスタンスが10000セッションの状態を持っていると、通常、サービス・インスタンスを増加することによって、その作業負荷を分担することは困難である。作業負荷がロックされている。逆に、プログラムが無状態に設計されているなら、サービスの実例を自由に増加させ、これらの例の間で負荷をバランスさせて、サービスがより良い伸縮性を持つようにすることができます。これは大規模な分散システムにおいて特に重要です。
リソースをはっきりとしたURLパスで表すと、クライアントがリソースをより理解しやすく操作することができる。URLは自己解釈のインターフェースとして見られ、説明を多くする必要がなく、そのURLがどのようなリソースを指しているのか、またどのように関連するリソースを獲得しているのかが分かります。
原則4：XMLまたはJSONを使用してデータサービスと要求を送信するメッセージデータには、リソースの属性についての記述が含まれており、サービスは構造が良く、読み取りが容易な方法でリソースを記述すべきである。XML、JSONは構造の良い言語で、読書に適しています。JSONはXMLよりもっと簡潔です。
RESTセキュリティ
REST/HTTPネットワークサービスが直接クライアントの前に露出して、サービスの安全を確保するにはどうすればいいですか？
REST/HTTPネットワークサービスの情報パッケージはファイアウォールによって理解され制御されます。操作とリンクに従って情報パッケージをフィルタリングしてもいいです。外部から来たのは自分のサーバーのリソースしか読み取れません。これは、システム管理者にとってソフトウェア管理をより簡単にする。
二：RESTのセキュリティは、伝送安全プロトコルSSL/TLS、HTTP基本認証と要約認証を利用することもできる。
HTTP 、 。 ， BASE64 ， 、 。 HTTP ， 。 Http ， HTTPS(SSL/TLS) 。
（digest authentication）
三：情報ベースのWeb Services Securityをセキュリティ認証の補完案として利用することもできる。
第三者オープンソースのOpenIDとOauthライブラリを安全認証方式の選択とします。