RESTfulプログラミングとは正確には何ですか？

RESTfulプログラミングとは正確には何ですか？

建築様式と呼ばれるREST（のRepresentational State Transferが）それがされたように、そのWebアプリケーションがHTTPを使用する必要があります提唱もともと想定します。ルックアップはGETリクエストを使用する必要があります。PUT、POSTとDELETEの要求が使用する必要があり、それぞれの変異、作成、および削除。

REST支持者は、次のようなURLを好む傾向があります。

http://myserver.com/catalog/item/1729

ただし、RESTアーキテクチャでは、これらの「きれいなURL」は必要ありません。パラメータ付きのGETリクエスト

http://myserver.com/catalog?item=1729

RESTfulとして少しです。

GETリクエストを情報の更新に使用しないでください。たとえば、カートにアイテムを追加するためのGETリクエスト

http://myserver.com/addToCart?cart=314159&item=1729

適切ではありません。GETリクエストはべき等である必要があります。つまり、リクエストを2回発行することは、1回発行することと同じです。これにより、リクエストがキャッシュ可能になります。「カートに追加」リクエストはべき等ではありません。2回発行すると、アイテムの2つのコピーがカートに追加されます。このコンテキストでは、POSTリクエストが明らかに適切です。したがって、RESTful Webアプリケーションでさえ、POSTリクエストの共有が必要です。

これは、David M. Gearyの著書『Core JavaServer faces』から抜粋したものです。

RESTは、Webの基盤となるアーキテクチャの原則です。Webの驚くべき点は、クライアント（ブラウザ）とサーバーが複雑な方法でやり取りできることです。クライアントがサーバーとホストするリソースについて事前に何も知らなくてもかまいません。重要な制約は、サーバーとクライアントの両方が、使用されるメディア（ Webの場合はHTML）に同意する必要があることです。

RESTの原則に準拠しているAPI では、クライアントがAPIの構造について何も知っている必要はありません。むしろ、サーバーは、クライアントがサービスと対話するために必要なあらゆる情報を提供する必要があります。HTMLフォームは、この例です：サーバーはリソースと必要なフィールドの位置を指定します。ブラウザは、情報をどこに送信するかを事前に知りません。また、どの情報を送信するかを事前に知りません。どちらの形式の情報も、サーバーによって完全に提供されます。（この原則はHATEOAS：アプリケーション状態のエンジンとしてのハイパーメディアと呼ばれます。）

では、これはHTTPにどのように適用され、実際にどのように実装できるのでしょうか。HTTPは動詞とリソースを中心としています。主流の用法における2つの動詞はGETandでありPOST、誰もが理解すると思います。ただし、HTTP標準では、PUTおよびなどの他のいくつかが定義されていDELETEます。次に、サーバーから提供される指示に従って、これらの動詞がリソースに適用されます。

たとえば、Webサービスによって管理されているユーザーデータベースがあるとします。当社のサービスは、我々はMIMEタイプを割り当てているためJSONに基づいてカスタムハイパーメディアを使用していますapplication/json+userdb（もあるかもしれませんapplication/xml+userdbし、application/whatever+userdb-多くのメディアタイプをサポートすることができます）。クライアントとサーバーはどちらもこの形式を理解するようにプログラムされていますが、お互いについては何も知りません。以下のようロイフィールディングは指摘します：

REST APIは、リソースの表現とアプリケーションの状態の駆動に使用されるメディアタイプの定義、または既存の標準メディアタイプの拡張リレーション名やハイパーテキスト対応マークアップの定義に、そのほとんどすべての記述的努力を費やすべきです。

基本リソースのリクエストは、/次のようなものを返す可能性があります。

リクエスト

GET /
Accept: application/json+userdb

応答

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

メディアの説明から、「リンク」というセクションから関連リソースに関する情報を見つけることができます。これはハイパーメディアコントロールと呼ばれます。この場合、そのようなセクションから、別のリクエストを行うことでユーザーリストを検索できることがわかります/user。

リクエスト

GET /user
Accept: application/json+userdb

応答

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

この反応から多くのことがわかります。たとえば、次のコマンドを実行して新しいユーザーを作成できることがわかりPOSTました/user。

リクエスト

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

応答

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

また、既存のデータを変更できることも知っています。

リクエスト

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

応答

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

我々は異なるHTTP動詞を使用していることに注意してください（GET、PUT、POST、DELETEなど）これらのリソースを操作し、そして私たちは、クライアントの一部に推定するだけの知識は、私たちのメディアの定義であることにします。

参考文献：

• このページにある多くのより良い答え。
• RESTを妻に説明した方法。
• RESTを妻に説明した方法。
• マーティン・ファウラーの考え
• PayPalのAPIにはハイパーメディアコントロールがあります

（この回答は、ポイントを逃したことに対するかなりの量の批判の対象となっています。ほとんどの場合、それはかなりの批判でした。最初に説明したのは、RESTが通常数年前に実装されたときの方法とより一致しています。本当の意味ではなく、最初にこれを書きました。本当の意味をよりよく表すために、答えを修正しました。）

RESTfulプログラミングとは：

• 永続的な識別子によって識別されるリソース：最近ではURIがユビキタスな識別子の選択です
• 動詞の共通セットを使用して操作されているリソースは：HTTPメソッドはよく見られるケースである-由緒Create、Retrieve、Update、DeleteとなるPOST、GET、PUT、およびDELETE。ただし、RESTはHTTPに限定されず、現在最も一般的に使用されているトランスポートです。
• リソースに対して取得される実際の表現は、識別子ではなく要求に依存します。Acceptヘッダーを使用して、XML、HTTP、またはリソースを表すJavaオブジェクトのいずれが必要かを制御します。
• オブジェクトの状態を維持し、状態を表現で表す
• リソースの表現におけるリソース間の関係の表現：オブジェクト間のリンクは表現に直接埋め込まれます
• リソース表現は、表現の使用方法と、どのような状況下で一貫した方法で破棄/再フェッチする必要があるかを説明します。HTTPキャッシュ制御ヘッダーの使用

最後の1つは、RESTの結果と全体的な有効性の点でおそらく最も重要です。全体として、RESTfulな議論のほとんどはHTTPとブラウザからのその使用法に焦点を当てているようですが、そうでないものもあります。R.フィールディングがHTTPにつながるアーキテクチャと決定について説明したときに、R。フィールディングがこの用語を作り出したと理解しています。彼の論文は、HTTPについてではなく、リソースのアーキテクチャとキャッシュ能力についてです。

RESTfulアーキテクチャとは何か、そしてなぜそれが機能するのかに本当に興味がある場合は、彼の論文を数回読み、第5章だけでなく全体を読んでください！次にDNSが機能する理由を調べます。DNSの階層構造と紹介の仕組みについて読んでください。次に、DNSキャッシュのしくみを読んで検討します。最後に、HTTP仕様（特にRFC2616とRFC3040）を読み、キャッシングがどのように、そしてなぜキャッシングが機能するのかを検討します。最終的には、クリックするだけです。私にとっての最後の啓示は、DNSとHTTPの類似点を見たときでした。この後、SOAとメッセージパッシングインターフェースがスケーラブルである理由を理解することから始めます。

RESTful アーキテクチャとShared Nothingアーキテクチャのアーキテクチャの重要性とパフォーマンスへの影響を理解するための最も重要なトリックは、テクノロジーと実装の詳細にこだわらないようにすることだと思います。リソースの所有者、リソースの作成/保守の責任者などに集中します。次に、表現、プロトコル、テクノロジーについて考えます。

これは次のようになります。

3つのプロパティを持つユーザーを作成します。

POST /user
fname=John&lname=Doe&age=25

サーバーは応答します：

200 OK
Location: /user/123

その後、ユーザー情報を取得できます。

GET /user/123

サーバーは応答します：

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

レコードを変更するには（lnameとage変わりません）：

PATCH /user/123
fname=Johnny

レコードを更新するには（その結果lnameとageNULLになります）：

PUT /user/123
fname=Johnny

RESTに関するすばらしい本はREST in Practiceです。

読み取りは、Representational State Transfer（REST）であり、REST APIはハイパーテキスト駆動である必要があります

RESTfulサービスとは何かについての説明は、Martin Fowlersの記事Richardson Maturity Model（RMM）を参照してください。

RESTfulであるためには、サービスはアプリケーション状態のエンジンとしてハイパーメディアを満たす必要があります。（HATEOAS）、つまり、RMMでレベル3に到達する必要があります。詳細については、記事またはqconトークのスライドを参照してください。

HATEOAS制約は、アプリケーション状態のエンジンとしてのハイパーメディアの頭字語です。この原則は、RESTと他のほとんどの形式のクライアントサーバーシステムとの主な差別化要因です。

...

RESTfulアプリケーションのクライアントは、それにアクセスするために単一の固定URLを知っているだけで済みます。今後のすべてのアクションは、そのURLから返されるリソースの表現に含まれているハイパーメディアリンクから動的に検出できる必要があります。標準化されたメディアタイプは、RESTful APIを使用する可能性のあるクライアントによって理解されることも期待されています。（ウィキペディア、フリー百科事典より）

REST Litmus Test for Web Frameworksは、Webフレームワークの同様の成熟度テストです。

純粋なRESTへのアプローチ：HATEOASを愛することを学ぶことは、リンクの良いコレクションです。

パブリッククラウドのRESTとSOAPの比較では、RESTの現在の使用レベルについて説明しています。

RESTとバージョン管理では、変更可能性を通じて、拡張性、バージョン管理、進化性などについて説明します

RESTとは何ですか？

RESTは、Representational State Transferの略です。（「ReST」と綴られることもあります。）ステートレスなクライアント/サーバー型のキャッシュ可能な通信プロトコルに依存しています。ほとんどすべての場合、HTTPプロトコルが使用されます。

RESTは、ネットワークアプリケーションを設計するためのアーキテクチャスタイルです。考え方は、CORBA、RPC、SOAPなどの複雑なメカニズムを使用してマシン間を接続するのではなく、単純なHTTPを使用してマシン間で呼び出しを行うというものです。

多くの点で、HTTPに基づくWorld Wide Web自体はRESTベースのアーキテクチャと見なすことができます。RESTfulアプリケーションはHTTPリクエストを使用して、データの投稿（作成や更新）、データの読み取り（クエリの作成など）、データの削除を行います。したがって、RESTは4つのCRUD（作成/読み取り/更新/削除）操作すべてにHTTPを使用します。

RESTは、RPC（リモートプロシージャコール）やWebサービス（SOAP、WSDLなど）のようなメカニズムの軽量な代替手段です。後で、RESTがいかにシンプルかを見ていきます。

シンプルであるにもかかわらず、RESTはフル機能を備えています。基本的に、RESTfulアーキテクチャーでは実行できないWebサービスでできることは何もありません。RESTは「標準」ではありません。たとえば、RESTに対するW3Cの推奨事項はありません。また、RESTプログラミングフレームワークはありますが、RESTの操作は非常に簡単なので、Perl、Java、C＃などの言語の標準ライブラリ機能を使用して「独自にロール」できることがよくあります。

休息の単純な本当の意味を見つけようとしたときに見つけた最高のリファレンスの1つ。

http://rest.elkstein.org/

RESTはさまざまなHTTPメソッド（主にGET / PUT / DELETE）を使用してデータを操作します。

特定のURLを使用してメソッド（たとえば、/user/123/delete）を削除するのではなく、DELETEリクエストを/user/[id]URLに送信してユーザーを編集し、GETリクエストを送信したユーザーに関する情報を取得します/user/[id]

たとえば、代わりに次のようなURLのセットです。

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

あなたは、HTTP "動詞"を使用します。

GET /user/2
DELETE /user/2
PUT /user

これは、システムのアーキテクチャが、Roy Fieldingが論文で提示したRESTスタイルに適合するプログラミングです。これはWebを（多かれ少なかれ）記述するアーキテクチャスタイルであるため、多くの人々がそれに興味を持っています。

おまけの回答：いいえ。ソフトウェアアーキテクチャを学術的またはデザイン用のWebサービスとして研究しているのでない限り、この用語を聞いた理由はありません。

RESTfulプログラミングとは、RESTアーキテクチャスタイルに従うシステム（API）を作成することです。

M.エルクシュタイン博士によるRESTに関するこの素晴らしく、短くて理解しやすいチュートリアルを見つけ、大部分の質問に答える重要な部分を引用しました。

RESTの学習：チュートリアル

RESTは、ネットワークアプリケーションを設計するためのアーキテクチャスタイルです。考え方は、CORBA、RPC、SOAPなどの複雑なメカニズムを使用してマシン間を接続するのではなく、単純なHTTPを使用してマシン間で呼び出しを行うというものです。

• 多くの点で、HTTPに基づくWorld Wide Web自体はRESTベースのアーキテクチャと見なすことができます。

RESTfulアプリケーションはHTTPリクエストを使用して、データの投稿（作成や更新）、データの読み取り（クエリの作成など）、データの削除を行います。したがって、RESTは4つのCRUD（作成/読み取り/更新/削除）操作すべてにHTTPを使用します。

スタックオーバーフローの外でRESTについて聞いていないのに馬鹿げているとは思わない...、私も同じ状況になるでしょう。なぜRESTが大きくなっているのかという、この別のSOの質問に対する答えは、いくつかの感情を和らげることができます。

質問に直接回答しないことをお詫び申し上げますが、より詳細な例を使用すると、これらすべてを理解する方が簡単です。フィールディングは、すべての抽象化と用語のため、理解が容易ではありません。

ここにかなり良い例があります：

RESTとハイパーテキストの説明：Spam-Eスパムクリーニングロボット

そしてさらに良いことに、ここには簡単な例を使った明確な説明があります（パワーポイントはより包括的ですが、ほとんどはHTMLバージョンで取得できます）。

http://www.xfront.com/REST.pptまたはhttp://www.xfront.com/REST.html

例を読んだ後、KenがRESTはハイパーテキスト駆動型であると言っている理由がわかりました。/ user / 123はリソースを指すURIであり、クライアントが「アウトオブバンド」であることを知っているからといって、RESTfulでないことはわかりません。

そのxfrontドキュメントはRESTとSOAPの違いを説明しており、これも非常に役立ちます。フィールディングが「RPCだ。RPCは悲鳴を上げる」と言ったとき、RPCがRESTfulではないことは明らかなので、これの正確な理由を確認することは有用です。（SOAPはRPCの一種です。）

RESTとは何ですか？

RESTは公式な言葉で言えば、現在の「Web」の基礎を使用した特定の原則に基づいて構築されたアーキテクチャスタイルです。RESTサービスを作成するために活用されるWebの5つの基本的な基本があります。

• 原則1：すべてがリソースであるRESTアーキテクチャスタイルでは、データと機能はリソースと見なされ、通常はWeb上のリンクであるURI（Uniform Resource Identifier）を使用してアクセスされます。
• 原則2：すべてのリソースは一意の識別子（URI）によって識別される
• 原則3：シンプルで統一されたインターフェースを使用する
• 原則4：表現によってコミュニケーションが行われる
• 原則5：無国籍であること

リソース「/ user / 123」にユーザー123に関するすべてを置くことはRESTfulであると言う答えがたくさんあります。

この用語を作り出したロイフィールディング氏は、REST APIはハイパーテキスト駆動である必要があると述べています。特に、「REST APIは固定のリソース名または階層を定義してはなりません」。

したがって、「/ user / 123」パスがクライアントでハードコーディングされている場合、それは実際にはRESTfulではありません。多分、そうでないかもしれませんが、HTTPの良い使い方です。しかしRESTfulではありません。それはハイパーテキストから来る必要があります。

答えは非常に簡単です。RoyFieldingによって書かれた論文があります。] 1その論文で、彼はRESTの原則を定義しています。アプリケーションがこれらの原則のすべてを満たしている場合、それはRESTアプリケーションです。

RESTfulという用語は、pplがREST以外のアプリケーションをRESTとして呼び出すことによりRESTという単語を使い果たしたために作成されました。その後、RESTfulという用語も使い果たされました。今日は、いわゆるRESTアプリケーションのほとんどが統一されたインターフェース制約のHATEOAS部分を満たさなかったため、Web APIとハイパーメディアAPIについて話しています。

REST制約は次のとおりです。

1. クライアントサーバーアーキテクチャ

   そのため、たとえばPUB / SUBソケットでは機能せず、REQ / REPに基づいています。

2. ステートレスコミュニケーション

   したがって、サーバーはクライアントの状態を維持しません。つまり、サーバー側のセッションストレージを使用できず、すべてのリクエストを認証する必要があります。クライアントは、暗号化された接続を介して基本認証ヘッダーを送信する可能性があります。（大きなアプリケーションでは、多くのセッションを維持するのは困難です。）

3. 可能であればキャッシュの使用

   したがって、同じリクエストを何度も処理する必要はありません。

4. クライアントとサーバー間の共通コントラクトとしての統一されたインターフェース

   クライアントとサーバー間の契約はサーバーによって維持されません。言い換えると、クライアントはサービスの実装から切り離されている必要があります。リソースを識別するためのIRI（URI）標準、メッセージを交換するためのHTTP標準、本文のシリアル化形式を説明するための標準MIMEタイプ、メタデータ（おそらくRDF語彙、マイクロフォーマットなど）などの標準ソリューションを使用して、この状態に到達できます。メッセージ本文のさまざまな部分のセマンティクスを記述します。IRI構造をクライアントから切り離すには、ハイパーリンクを（HTML、JSON-LD、HALなど）のようなハイパーメディア形式でクライアントに送信する必要があります。したがって、クライアントは、ハイパーリンクに割り当てられたメタデータ（リンク関係、RDF単語など）を使用して、現在の目標を達成するために、適切な状態遷移を通じてアプリケーションの状態マシンをナビゲートできます。

   たとえば、クライアントが注文をWebショップに送信したい場合、Webショップが送信した応答のハイパーリンクを確認する必要があります。リンクをチェックすると、http: //schema.org/OrderActionで記述されたリンクが見つかります。クライアントはschema.orgの語彙を知っているため、このハイパーリンクをアクティブにすることで注文が送信されることを理解しています。したがって、ハイパーリンクをアクティブにPOST https://example.com/api/v1/orderし、適切な本文を含むメッセージを送信します。その後、サービスはメッセージを処理し、201 - created成功などの適切なHTTPステータスヘッダーを持つ結果で応答します。詳細なメタデータを使用してメッセージに注釈を付けるには、RDF形式を使用するための標準的なソリューション、たとえばREST 語彙を含むJSON-LD、たとえばHydraやドメイン固有の語彙などschema.orgまたはその他のリンクされたデータ語彙、および必要に応じてカスタムアプリケーション固有の語彙。これは簡単ではありません。そのため、ほとんどのPPLはHALおよびその他の単純な形式を使用するので、通常はREST語彙のみが提供され、リンクされたデータはサポートされません。

5. 階層化システムを構築してスケーラビリティを向上させる

   RESTシステムは階層的なレイヤーで構成されています。各層には、下の次の層にあるコンポーネントのサービスを使用するコンポーネントが含まれています。したがって、新しいレイヤーやコンポーネントを簡単に追加できます。

   たとえば、クライアントを含むクライアント層があり、その下に単一のサービスを含むサービス層があります。これで、それらの間にクライアント側キャッシュを追加できます。その後、別のサービスインスタンスやロードバランサーなどを追加できます。クライアントコードとサービスコードは変更されません。

6. クライアント機能を拡張するためのオンデマンドコード

   この制約はオプションです。たとえば、特定のメディアタイプのパーサーをクライアントに送信できます。これを行うには、クライアントに標準のプラグインローダーシステムが必要になるか、クライアントがプラグインローダーソリューションに結合されます。 。

REST制約は、クライアントがサービスの実装から切り離された、非常にスケーラブルなシステムをもたらします。そのため、クライアントはWeb上のブラウザーと同じように、一般的に再利用できます。クライアントとサービスは同じ標準と語彙を共有するため、クライアントはサービスの実装の詳細を知らなくても、お互いを理解できます。これにより、RESTサービスを見つけて利用し、目標を達成できる自動クライアントを作成できます。長期的には、これらのクライアントは、人間と同じように、相互に通信し、相互にタスクを信頼できます。そのようなクライアントに学習パターンを追加すると、単一のサーバーパークではなく、マシンのWebを使用して1つ以上のAIが生成されます。それで、最後にバーナーズ・リーの夢：セマンティックウェブと人工知能が現実になります。そのため、2030年にスカイネットによって終了させられました。それまで ... ;-）

RESTful（Representational State Transfer）APIプログラミングは、5つの基本的なソフトウェアアーキテクチャスタイルの原則に従って、任意のプログラミング言語でWebアプリケーションを作成します。

1. リソース（データ、情報）。
2. 一意のグローバル識別子（すべてのリソースはURIによって一意に識別されます）。
3. 統一インターフェース -シンプルで標準的なインターフェース（HTTP）を使用します。
4. 表現-すべての通信は表現によって行われます（例：XML / JSON）
5. ステートレス（すべてのリクエストは完全に分離して発生し、キャッシュと負荷分散が容易です）、

言い換えれば、GET、POST、PUT、DELETEなどの動詞を使用するHTTP経由のシンプルなポイントツーポイントネットワークアプリケーションを作成し、各「リソース」が公開するインターフェースの標準化を提案するRESTfulアーキテクチャを実装します。シンプルで効果的な方法でWebの現在の機能を使用することは何もありません（非常に成功した実績のある分散アーキテクチャ）。これは、SOAP、CORBA、RPCなどのより複雑なメカニズムの代替手段です。

RESTfulプログラミングはWebアーキテクチャ設計に準拠しており、適切に実装されていれば、スケーラブルなWebインフラストラクチャを最大限に活用できます。

RESTの元の論文を3つの短い文に減らす必要がある場合、次のようにその本質を捉えていると思います。

1. リソースはURL経由でリクエストされます。
2. プロトコルは、URLを使用して通信できるものに制限されます。
3. メタデータは名前と値のペア（投稿データとクエリ文字列パラメーター）として渡されます。

その後、適応、コーディング規約、およびベストプラクティスについての議論に陥るのは簡単です。

興味深いことに、論文ではHTTP POST、GET、DELETE、またはPUT操作については言及されていません。これは、「統一されたインターフェース」の「ベストプラクティス」を誰かが後で解釈したものでなければなりません。

Webサービスに関しては、WSDLとSOAPベースのアーキテクチャを区別するためのいくつかの方法が必要と思われます。これにより、オーバーヘッドが大幅に増加し、インターフェイスに不必要な複雑さが間違いなく追加されます。また、実装するために追加のフレームワークと開発者ツールも必要です。RESTが常識的なインターフェースと、WSDLやSOAPなどの過度に設計されたインターフェースを区別するのに最適な用語かどうかはわかりません。しかし、私たちは何かが必要です。

RESTは、分散アプリケーションを作成するためのアーキテクチャパターンおよびスタイルです。狭義のプログラミングスタイルではありません。

RESTスタイルを使用すると言うことは、チューダーやビクトリア朝などの特定のスタイルで家を建てたと言うことと似ています。ソフトウェアスタイルとしてのRESTとホームスタイルとしてのTudorまたはVictorianは、それらを構成する品質と制約によって定義できます。たとえば、RESTにはメッセージが自己記述的であるクライアントサーバー分離が必要です。チューダー様式の家には、正面切妻と急勾配の切妻と屋根が重なっています。Royの論文を読んで、RESTを構成する制約と品質について詳しく学んでください。

ホームスタイルとは異なり、RESTは一貫して実際に適用されるのに苦労しました。これは意図的なものであった可能性があります。実際の実装は設計者に任せます。したがって、RESTシステムを作成している論文で設定された制約を満たしている限り、自由に好きなことができます。

ボーナス：

Web全体がRESTに基づいています（またはRESTはWebに基づいていました）。したがって、Web開発者は、優れたWebアプリケーションを作成する必要はありませんが、そのことを認識しておく必要があります。

RESTの基本的な概要は次のとおりです。概念を理解することがより直感的になるように、RESTfulアーキテクチャーの各コンポーネントの背後にある考え方を実証しようとしました。うまくいけば、これは一部の人にとってRESTをわかりやすく説明するのに役立ちます！

REST（Representational State Transfer）は、ネットワーク化されたリソース（つまり、情報を共有するノード）がどのように設計されて対処されるかを概説する設計アーキテクチャーです。一般に、RESTfulアーキテクチャでは、クライアント（要求側のマシン）とサーバー（応答側のマシン）がデータの読み取り、書き込み、更新を要求できるようになっています。クライアントがサーバーの動作方法を知らなくても、サーバーはデータを渡すことができます。クライアントについて何も知る必要なくそれを元に戻します。わかりました、かっこいいです...しかし、実際にこれをどのように行うのですか？

• 最も明白な要件は、サーバーがクライアントが要求に対して何をしようとしているかをサーバーに伝え、サーバーが応答できるように、何らかの汎用言語が必要であることです。

• しかし、特定のリソースを見つけて、そのリソースがどこにあるかをクライアントに伝えるには、リソースを指す普遍的な方法が必要です。これは、Universal Resource Identifier（URI）の出番です。それらは基本的にリソースを見つけるための一意のアドレスです。

しかし、RESTアーキテクチャはそこで終わりません！上記は私たちが望む基本的なニーズを満たしますが、特定のサーバーは通常複数のクライアントからの応答を処理するため、大量のトラフィックをサポートするアーキテクチャも必要です。したがって、以前のリクエストに関する情報をサーバーに記憶させることでサーバーを圧倒したくありません。

• したがって、クライアントとサーバー間の各要求と応答のペアは独立しているという制限を課します。つまり、サーバーは新しい要求に応答するために以前の要求（クライアントとサーバーの相互作用の以前の状態）について何も覚えておく必要がないということですリクエスト。これは、相互作用がステートレスであることを望んでいることを意味します。

• RESTは、特定のクライアントに対して最近行われた計算をやり直すことによるサーバーの負担をさらに軽減するために、キャッシュも許可します。基本的に、キャッシングとは、クライアントに提供された初期応答のスナップショットを取ることです。クライアントが同じ要求を再度行う場合、サーバーは、初期応答を作成するために必要なすべての計算をやり直すのではなく、スナップショットをクライアントに提供できます。ただし、スナップショットであるため、スナップショットの有効期限が切れていない場合（サーバーは事前に有効期限を設定しています）、応答は初期キャッシュ以降に更新されています（つまり、要求はキャッシュされた応答とは異なる応答を返します）。 、クライアントは、キャッシュの有効期限が切れ（またはキャッシュがクリアされ）、応答が最初からレンダリングされるまで、更新を表示しません。

• RESTfulアーキテクチャーに関してここでよく目にする最後のことは、それらが階層化されていることです。この要件については、クライアントとサーバー間の相互作用についての議論ですでに暗黙のうちに議論されています。基本的に、これは、システムの各レイヤーが隣接するレイヤーとのみ相互作用することを意味します。したがって、私たちの議論では、クライアント層はサーバー層と相互作用します（逆も同様です）が、クライアントが直接通信しない要求をプライマリサーバーが処理するのを助ける他のサーバー層があるかもしれません。むしろ、サーバーは必要に応じてリクエストを渡します。

さて、これらすべてがおなじみのように聞こえるなら、素晴らしいです。World Wide Webを介した通信プロトコルを定義するハイパーテキスト転送プロトコル（HTTP）は、RESTfulアーキテクチャ（または私のようなOOP狂信者であればRESTクラスのインスタンス）の抽象的な概念の実装です。RESTのこの実装では、クライアントとサーバーはGET、POST、PUT、DELETEなどを介して対話します。これらは、ユニバーサル言語の一部であり、リソースはURLを使用してポイントできます。

安らぎのポイントは、ステートレスなトランスポート層としてインターネット（プロトコル）を利用しながら、ステートフルネスを上位層に分離することだと思います。他のほとんどのアプローチは物事を混同します。

これは、インターネット時代のプログラミングの根本的な変化に対処するための最良の実践的アプローチでした。根本的な変更に関して、エリックマイヤーはここでショーについて議論しています：http : //www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197。彼はそれを5つの効果として要約し、ソリューションをプログラミング言語に設計することによってソリューションを提示します。ソリューションは、言語に関係なく、プラットフォームまたはシステムレベルでも実現できます。安静は、現在の実践で非常に成功しているソリューションの1つと見なすことができます。

落ち着いたスタイルで、信頼できないインターネットを介してアプリケーションの状態を取得して操作します。正しい現在の状態を取得するために現在の操作が失敗した場合、アプリケーションの続行を支援するためにゼロ検証プリンシパルが必要です。状態の操作に失敗した場合は、通常、確認の複数の段階を使用して状況を正しく保ちます。この意味で、残りはそれ自体が完全なソリューションではなく、その動作をサポートするためにWebアプリケーションスタックの他の部分の関数を必要とします。

この観点から考えると、残りのスタイルは実際にはインターネットまたはWebアプリケーションに関連付けられていません。これは、多くのプログラミング状況に対する基本的な解決策です。それも単純ではなく、インターフェースを本当にシンプルにし、他のテクノロジーに驚くほどうまく対応します。

ちょうど私の2c。

編集：さらに2つの重要な側面：

• 無国籍は誤解を招くものです。これは、アプリケーションやシステムではなく、Restful APIに関するものです。システムはステートフルである必要があります。安静設計とは、ステートレスAPIに基づいてステートフルシステムを設計することです。いくつかの別のQAからの引用：

  • RESTは、それぞれがURLで識別されるリソース表現で動作します。これらは通常、データオブジェクトではなく、複雑なオブジェクトの抽象化です。
  • RESTは「表現状態転送」の略です。つまり、システム内のリソースの状態を通信および変更することがすべてです。

• べき等：RESTで見過ごされがちな部分は、ほとんどの動詞のべき等です。これにより、堅牢なシステムが実現し、セマンティクスの正確な解釈の相互依存性が低下します。

これは驚くほど長い「議論」ですが、控えめに言ってもかなり混乱します。

IMO：

1）大きな共同作業とたくさんのビールがなければ、安らかなプログラミングのようなものはありません:)

2）Representational State Transfer（REST）は、Roy Fieldingの論文で指定された建築スタイルです。これにはいくつかの制約があります。サービス/クライアントがそれらを尊重する場合、それはRESTfulです。これだよ。

次の制約を（大幅に）要約できます。

• ステートレスコミュニケーション
• HTTP仕様を尊重する（HTTPが使用されている場合）
• 送信されたコンテンツ形式を明確に伝える
• アプリケーション状態のエンジンとしてハイパーメディアを使用する

物事をうまく説明する別の非常に良い投稿があります。

多くの回答は、有効な情報をコピーして貼り付け、混乱させています。人々はここでレベル、RESTFul URI（そのようなものはありません！）について話し、HTTPメソッドGET、POST、PUTを適用します... RESTはそれだけではなく、それだけではありません。

たとえばリンク-見栄えの良いAPIを用意するのは良いことですが、クライアント/サーバーは、取得/送信するリンクを本当に気にしません。重要なのはコンテンツです。

結局のところ、RESTfulクライアントは、コンテンツ形式がわかっている限り、RESTfulサービスを利用できる必要があります。

古い質問、新しい答え方。この概念については、多くの誤解があります。私はいつも思い出そうとします：

1. 構造化URLとHttpメソッド/動詞は、落ち着いたプログラミングの定義ではありません。
2. JSONは安らかなプログラミングではありません
3. RESTfulプログラミングはAPI向けではありません

私は安らかなプログラミングを次のように定義します

クライアントが理解できるメディアタイプでリソース（データ+状態遷移制御の組み合わせ）を提供する場合、アプリケーションは安らぎます

落ち着いたプログラマーになるには、アクターが物事を行えるようにするアプリケーションを構築する必要があります。データベースを公開するだけではありません。

状態遷移制御は、クライアントとサーバーがリソースのメディアタイプ表現について合意した場合にのみ意味があります。それ以外の場合は、コントロールとは何か、そうでないものと、コントロールを実行する方法を知る方法はありません。IEがブラウザー<form>でHTMLのタグを認識していなかった場合、ブラウザーで遷移状態に送信するものは何もありません。

私は自分で宣伝するつもりはありませんが、これらのアイデアを講演http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.htmlで深く掘り下げています。

私の話からの抜粋は、リチャードソン成熟度モデルと呼ばれることが多いですが、レベルを信じていません。 RESTfulへの途中であなたのために行います

RESTは、あらゆるWebサービスを実現する6つのアーキテクチャ上の制約、つまり真のRESTful APIを定義しています。

1. 均一なインターフェース
2. クライアントサーバー
3. ステートレス
4. キャッシュ可能
5. 階層化システム
6. オンデマンドコード（オプション）

https://restfulapi.net/rest-architectural-constraints/

REST === HTTPの類推は、HATEOAS駆動である必要があるという事実を強調しない限り、正しくありません。

ロイ自身がここでそれをクリアしました。

REST APIは、初期URI（ブックマーク）と、対象とする対象者に適した標準化されたメディアタイプのセット（つまり、APIを使用する可能性のあるすべてのクライアントによって理解されることが期待される）以外の事前知識なしで入力する必要があります。その時点から、すべてのアプリケーションの状態遷移は、受信した表現に存在する、またはそれらの表現のユーザー操作によって暗示される、サーバー提供の選択肢のクライアント選択によって駆動される必要があります。遷移は、クライアントのメディアタイプとリソース通信メカニズムの知識を決定（または制限）できます。どちらもオンザフライで改善できます（たとえば、コードオンデマンド）。

[ここでの失敗は、帯域外情報がハイパーテキストではなく対話を促進していることを意味します。]

RESTは、Web標準とHTTPプロトコル（2000年に導入）に基づくアーキテクチャスタイルです。

RESTベースのアーキテクチャでは、すべてがリソース（ユーザー、注文、コメント）です。リソースは、HTTP標準メソッド（GET、PUT、PATCH、DELETEなど）に基づく共通インターフェースを介してアクセスされます。

RESTベースのアーキテクチャーには、リソースへのアクセスを提供するRESTサーバーがあります。RESTクライアントはRESTリソースにアクセスして変更できます。

すべてのリソースがHTTP共通操作をサポートする必要があります。リソースはグローバルID（通常はURI）で識別されます。

RESTでは、リソースにテキスト、XML、JSONなどのさまざまな表現を含めることができます。RESTクライアントは、HTTPプロトコル（コンテンツネゴシエーション）を介して特定の表現を要求できます。

HTTPメソッド：

PUT、GET、POST、およびDELETEメソッドは、RESTベースのアーキテクチャで一般的に使用されています。次の表に、これらの操作の説明を示します。

• GETは、副作用のないリソースの読み取りアクセスを定義します。リソースはGETリクエストによって変更されることはありません。たとえば、リクエストには副作用がありません（べき等）。
• PUTは新しいリソースを作成します。また、べき等である必要があります。
• DELETEはリソースを削除します。操作はべき等です。彼らは異なる結果につながることなく繰り返されることができます。
• POSTは、既存のリソースを更新するか、新しいリソースを作成します。

RESTは、Representational State Transferの略です。

ステートレスでクライアント/サーバー間でキャッシュ可能な通信プロトコルに依存しています。ほとんどすべての場合、HTTPプロトコルが使用されます。

RESTは、モバイルアプリケーション、ソーシャルネットワーキングWebサイト、マッシュアップツール、自動化されたビジネスプロセスでよく使用されます。RESTスタイルは、限られた数の操作（動詞）を使用することにより、クライアントとサービス間の対話が強化されることを強調しています。柔軟性は、リソース（名詞）に独自の一意のユニバーサルリソースインジケータ（URI）を割り当てることによって提供されます。

休息についての紹介

話すことは単に情報を交換するだけではありません。プロトコルは、実際には話が発生しないように設計されています。プロトコルで指定されているため、各当事者は特定のジョブが何であるかを知っています。プロトコルは、可能なアクションに変更を加える代わりに、純粋な情報交換を可能にします。一方、話すことにより、一方の当事者が他方の当事者からどのようなアクションを実行できるかを尋ねることができます。相手の州が暫定的に変更された可能性があるため、同じ質問を2回行って2つの異なる回答を得ることができます。話すことはRESTfulなアーキテクチャです。フィールディングの論文は、マシンが単に相互に通信することを許可したい場合、従わなければならないアーキテクチャを指定していますコミュニケーションする。

それ自体「RESTfulプログラミング」のような概念はありません。それは、RESTfulパラダイムまたはより優れたRESTfulアーキテクチャと呼ばれる方がよいでしょう。それはプログラミング言語ではありません。それはパラダイムです。

ウィキペディアから：

コンピューティングでは、Representational State Transfer（REST）はWeb開発に使用されるアーキテクチャスタイルです。

残りのポイントは、基本的な操作（http動詞）に共通の言語を使用することに同意した場合、インフラストラクチャは、それらを理解し、適切に最適化するように構成できます。レベル。

適切に実装されたRESTful GET操作を使用すると、サーバーのDB、サーバーのmemcache、CDN、プロキシのキャッシュ、ブラウザーのキャッシュ、またはブラウザーのローカルストレージからの情報であるかどうかは問題になりません。断食された、最も容易に入手可能な最新の情報源を使用できます。

Restは、actionパラメーターを指定したGETリクエストの使用から利用可能なhttp動詞の使用への構文上の変更にすぎないと言うと、利点がないように見え、純粋に表面的なものです。ポイントは、チェーンのすべての部分で理解および最適化できる言語を使用することです。GET操作に副作用のあるアクションがある場合、すべてのHTTPキャッシングをスキップする必要があります。そうしないと、結果に一貫性がなくなります。

APIテストとは何ですか？

APIテストでは、プログラミングを使用してAPIに呼び出しを送信し、収量を取得します。テストでは、テスト中のセグメントをブラックボックスと見なします。APIテストの目的は、アプリケーションへの調整に先立つ部分の適切な実行と誤解の扱いを確認することです。

REST API

REST：表現状態転送。

• これは、テスターが要求を実行して応答を受け取る機能の配置です。REST APIでは、対話はHTTPプロトコルを介して行われます。
• RESTは、ネットワークを介したコンピュータ間の相互通信も可能にします。
• メッセージの送受信には、HTTPメソッドを使用する必要があり、Webサービスとは異なり、厳密なメッセージ定義は必要ありません。
• RESTメッセージは、多くの場合、XMLまたはJavaScript Object Notation（JSON）のいずれかの形式を受け入れます。

4一般的に使用されるAPIメソッド：-

1. GET：–リソースへの読み取り専用アクセスを提供します。
2. POST：–新しいリソースを作成または更新するために使用されます。
3. PUT：–既存のリソースを更新または置換するため、または新しいリソースを作成するために使用されます。
4. DELETE：–リソースを削除するために使用されます。

APIを手動でテストする手順：-

APIを手動で使用するには、ブラウザーベースのREST APIプラグインを使用できます。

1. POSTMAN（Chrome）/ REST（Firefox）プラグインをインストールする
2. API URLを入力してください
3. RESTメソッドを選択します
4. コンテンツヘッダーを選択
5. リクエストJSON（POST）を入力してください
6. 送信をクリックします
7. 出力応答を返します

REST APIを自動化する手順

これについてはあまり言及されていませんが、Richardsonの成熟度モデルは、RestfulがAPIであるかどうかを実際に判断するための最良の方法の1つです。詳細はこちら：

リチャードソンの成熟度モデル

RESTを理解する上で重要な構成要素は、次のようなエンドポイントまたはマッピングにあると思います。 /customers/{id}/balance。

このようなエンドポイントは、Webサイト（フロントエンド）からデータベース/サーバー（バックエンド）への接続パイプラインであると想像できます。それらを使用して、フロントエンドは、アプリケーションのRESTマッピングの対応するメソッドで定義されているバックエンド操作を実行できます。