web-dev-qa-db-ja.com

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

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

httprestdefinition
3835
hasen

アーキテクチャスタイルと呼ばれる 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リクエストは idempotent でなければなりません。つまり、リクエストを2回発行しても、1回発行しても変わらないはずです。それがリクエストをキャッシュ可能にするものです。 「カートに追加」リクエストはべき等ではありません。2回発行すると、アイテムの2つのコピーがカートに追加されます。このコンテキストでは、POSTリクエストが明らかに適切です。したがって、RESTful Webアプリケーションでさえ、POSTリクエストのシェアを必要とします。

これは、David M. Gearyによる優れた本Core JavaServer facesの本から引用したものです。

686
Shirgill Farhan

RESTはWebの基本的なアーキテクチャの原則です。 Webについての驚くべきことは、クライアント（ブラウザ）とサーバが複雑な方法で対話することができるということです。クライアントはサーバとそれがホストするリソースについて事前に何も知らない。重要な制約は、サーバーとクライアントの両方がmediaの使用に同意しなければならないということです（Webの場合はHTML）。

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

それでは、これはHTTPにどのように当てはまるのでしょうか。 HTTPは動詞とリソースを中心としています。主流の用法における2つの動詞はGETとPOSTです、そして、私は誰もが認めると思います。ただし、HTTP規格では、PUTやDELETEなど、他のいくつかの定義があります。これらの動詞は、サーバーから提供される指示に従って、リソースに適用されます。

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

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

基本リソース/に対する要求は、次のようなものを返す可能性があります。

リクエスト 

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"
        }
    ]
}

この回答から多くのことがわかります。たとえば、/userにPOSTすることで新しいユーザーを作成できることがわかりました。

リクエスト 

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が通常どのように実装されたかに沿ったものでした。本当の意味ではなく、数年前に私が最初にこれを書いたとき、私は答えを修正して本当の意味をよりよく表すようにしました。）

2842
Emil H

RESTfulプログラミングの概要：

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

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

RESTfulアーキテクチャとは何か、なぜ機能するのかに本当に興味がある場合は、 his thesis を数回読み、第5章だけでなくwhole thingを読んでください！次に、 DNSが機能する理由 を調べます。 DNSの階層構造と紹介の仕組みについて読んでください。次に、DNSキャッシングの仕組みを読んで検討します。最後に、HTTP仕様（ RFC2616 および RFC304 特に）を読み、キャッシングが機能する方法と理由を検討します。最終的には、クリックするだけです。私にとって最後の啓示は、DNSとHTTPの類似点を見たときでした。この後、SOAおよびMessage Passing Interfaceがスケーラブルである理由を理解することから始めます。

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

525
D.Shawley

これはそれがどのように見えるかです。

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とageはNULLになります）、

PUT /user/123
fname=Johnny
401
pbreitenbach

RESTのすばらしい本は REST in Practice です。

読み取りが必要です Representational State Transfer（REST） および REST APIはハイパーテキスト駆動でなければなりません

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

Richardson Maturity Model

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

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

...

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

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

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

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

RESTおよびバージョニング は、拡張性、バージョニング、進化性などを変更可能性について説明します。

179
oluies

RESTとは何ですか？

RESTはRepresentational State Transferの略です。ステートレス、クライアント/サーバー型、キャッシュ可能な通信プロトコルに依存しています - そして、ほとんどの場合、HTTP プロトコルが使用されています。中古。

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

多くの点で、HTTPに基づくWorld Wide Web自体はRESTベースのアーキテクチャと見なすことができます。 ＲＥＳＴｆｕｌアプリケーションは、データの投稿（作成および／または更新）、データの読み取り（たとえば、問い合わせ）、［．．．］、およびデータの削除にＨＴＴＰリクエスト［．．．］を使用する。したがって、RESTは、4つすべてのCRUD （作成/読み取り/更新/削除）操作にHTTPを使用します。

RESTは、RPC（Remote Procedure Calls）やWebサービス（SOAP、WSDLなど）のようなメカニズムに代わる軽量のものです。後で、 RESTがどれほど単純かを見ていきます。

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

私が休息の単純な本当の意味を見つけようとしたとき私が見つけた最も良い参考文献のうちの1つ。

http://rest.elkstein.org/ /

132
Ravi

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

特定のURLを使用してメソッドを削除するのではなく（/user/123/delete）、/user/[id]のURLにDELETE要求を送信し、ユーザーを編集し、/user/[id]にGET要求を送信してユーザーの情報を取得します

たとえば、代わりに次のような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
88
dbr

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

ボーナス回答：いいえ。学術的なものとして、またはWebサービスを設計するものとしてソフトウェアアーキテクチャを研究しているのでなければ、その用語を聞いたことがある理由は本当にありません。

67
Hank Gay

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

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

説明RESTおよびハイパーテキスト：Spam-Eスパム駆除ロボット

さらに良いことに、ここに簡単な例を使ったわかりやすい説明があります（PowerPointはより包括的ですが、ほとんどはhtml版で入手できます）。

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

例を読んだ後、私はなぜKenがRESTがハイパーテキスト駆動であると言っているのかを見ることができました。その/ user/123はリソースを指すURIであり、クライアントがそれを「アウトオブバンド」と認識しているからといってそれが無駄であることは私には明らかではありません。

そのxfrontドキュメントはRESTとSOAPの違いを説明しています、そしてこれも本当に役に立ちます。 Fieldingが「 それはRPCです。それはRPCを絶賛します。 」と言うとき、RPCがRESTfulではないことは明らかですので、正確な理由を知ることは有用です。 （SOAPはRPCの一種です。）

45
tompark

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

M. Elkstein博士によるRESTについてのこの素晴らしく、短く、そして理解しやすいチュートリアルを見つけ、あなたの質問に最もよく答えるための本質的な部分を引用しました：

RESTを学ぶ：チュートリアル

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

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

ＲＥＳＴｆｕｌアプリケーションは、データの投稿（作成および／または［．．．．］更新）、データの読み取り（たとえば、クエリの作成）、およびデータの削除にＨＴＴＰ要求を使用する。したがって、REST は4つすべてのCRUD（作成/読み取り/更新/削除）操作にHTTPを使用します。

Stack Overflowの外でRESTを聞いていないことにばかげているべきではないと思いますが、私は同じ状況にいるでしょう。この他のSO質問への回答/ なぜRESTが大きくなっているのか 気持ちを和らげることができます。

44
Only You

RESTとは何ですか？

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

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

私は、ユーザー123に関するすべてをリソース "/ user/123"に置くことがRESTfulであるというたくさんの答えを見ました。

この用語を作り出したRoy Fieldingは、 REST AP​​Iはハイパーテキスト主導でなければならない と言います。特に、 "A REST AP​​Iは固定のリソース名や階層を定義してはいけません"。

あなたの "/ user/123"パスがクライアント上でハードコードされているのであれば、それは本当にRESTfulではありません。 HTTPを上手く利用しているのではないでしょうか。しかしRESTfulではありません。それはハイパーテキストから来なければなりません。

34
Ken

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

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

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

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

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

  2. ステートレス通信

    そのため、サーバーはクライアントの状態を維持しません。つまり、サーバー側のセッション記憶域を使用することはできず、すべての要求を認証する必要があります。あなたのクライアントはおそらく暗号化された接続を通して基本的な認証ヘッダを送る。 （大規模なアプリケーションでは、多くのセッションを維持するのは困難です。）

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

    だからあなたは何度も何度も同じ要求を提供する必要はありません。

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

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

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

  5. スケーラビリティを高めるために階層化システムを構築する

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

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

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

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

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

26
inf3rno

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

  1. リソース（データ、情報）.
  2. 一意のグローバル識別子 （すべてのリソースは、 URI によって識別される一意です）。
  3. Uniform interface - シンプルで標準的なインターフェース（HTTP）を使います。
  4. 表現 - すべてのコミュニケーションは表現によって行われます（例： XML / JSON ）
  5. Stateless （すべてのリクエストは完全に独立して行われるため、キャッシュとロードバランスがより簡単になります）、

言い換えれば、GET、POST、PUT、DELETEなどの動詞を使用するHTTPを介した単純なポイントツーポイントネットワークアプリケーションを作成しています。 Webの現在の機能を単純で効果的な方法で使用すること（成功し、実績があり、分散されたアーキテクチャ）は意味がありません。これは、 SOAP 、 CORBA 、および RPC のようなより複雑なメカニズムに代わるものです。 

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

20
kenorb

私がRESTの元の論文を3つの短い文に減らさなければならないなら、私は以下がその本質を捉えていると思います：

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

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

興味深いことに、学位論文にはHTTP POST、GET、DELETE、またはPUT操作に関する記述はありません。それは、「統一インターフェース」のための「ベストプラクティス」の誰かによる後の解釈に違いない。

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

17
Nathan Andelin

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

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

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

  • しかし、与えられたリソースを見つけて、そのリソースがどこにあるのかをクライアントに伝えるためには、リソースを指す一般的な方法が必要です。これがユニバーサルリソース識別子（URI）が登場するところです。それらは基本的にリソースを見つけるためのユニークなアドレスです。

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

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

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

  • RESTfulアーキテクチャーに関してここでよく言う最後のことは、それらが階層化されているということです。実際には、クライアントとサーバー間のやり取りについての説明で、この要件について既に暗黙のうちに説明しています。基本的に、これは私たちのシステムの各層が隣接する層とだけ相互作用することを意味します。そのため、ここでの説明では、クライアント層はサーバー層と相互作用します（その逆も同様）が、プライマリサーバーがクライアントと直接通信しない要求を処理するのに役立つサーバー層が他にもあります。そうではなく、サーバーは必要に応じて要求を渡します。

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

17
Kal

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

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

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

ボーナス：

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

17
suing

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

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

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

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

ちょうど私の2c。

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

15
minghua

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

IMO：

1）大きな関節やたくさんのビールがなければ、落ち着いたプログラミングのようなことはありません:)

2） Representational State Transfer（REST）は、 Roy Fieldingの論文 。で指定されているアーキテクチャスタイルです。これには多くの制約があります。あなたのサービス/クライアントがそれらを尊重すればそれはRESTfulです。 これで終わりです。 

以下の制約を（大幅に）要約することができます。

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

もう一つの とても良い投稿があります これは物事をうまく説明しています。

多くの答えがそれを混ぜ合わせて混乱を加えている有効な情報をコピー/貼り付けしました。ここでは、レベルについて、RESTFul URIについて（そういうことはありません！）、HTTPメソッドGET、POST、PUTを適用します... RESTはそれについてではなく、それだけではありません。

例えばリンク - きれいに見えるAPIを持っているのはいいことですが、結局クライアント/サーバはあなたが得たり送ったりするリンクを本当に気にしていません。それは重要な内容です。 

最後に コンテンツフォーマットがわかっている限り、あらゆるRESTfulクライアントはあらゆるRESTfulサービスを利用できるはずです。

14
djodjo

REST === HTTPのアナロジーは、 _ hateoas _ に駆動されなければならないという事実を強調しない限り正しくありません。 

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

REST AP​​Iは、最初のURI（ブックマーク）と、対象とする視聴者に適した標準化されたメディアタイプのセットを超えた事前知識なしで入力する必要があります。 API）それ以降、すべてのアプリケーション状態遷移は、受信した表現に存在するか、またはそれらの表現に対するユーザーの操作によって暗黙的に示されるサーバー提供の選択肢のクライアント選択によって駆動される必要があります。移行は、メディアタイプおよびリソース通信メカニズムについてのクライアントの知識によって決定され（またはそれによって制限され）、その両方がオンザフライで改善され得る（たとえば、コードオンデマンド）。 

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

11
lokesh

昔の質問、新しい答え方。この概念については多くの誤解があります。私はいつも覚えています：

  1. 構造化URLとHTTPメソッド/動詞は安らかなプログラミングの定義ではありません。 
  2. JSONは安らかなプログラミングではありません
  3. RESTfulプログラミングはAPI用ではありません

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

アプリケーションがクライアントが理解できるメディアタイプでリソース（データ+状態遷移制御の組み合わせであること）を提供している場合、そのアプリケーションは休止しています。

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

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

私は自己宣伝するつもりはありませんが、私は私の話の中でこれらのアイデアを非常に深く展開しています http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html 。

私の話からの抜粋は、よく参照されるリチャードソン成熟度モデルについてです。私はレベルを信じていません、あなたはRESTful（レベル3）であるか、あなたはそうではありません。 RESTfulへの道をあなたのためにやる

annotated richardson maturity model

11
Chris DaMour

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

RESTベースのアーキテクチャでは、すべてがリソース（Users、Orders、Comments）です。リソースは、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は既存のリソースを更新するか、または新しいリソースを作成します。
11
Imran

RESTはあらゆるWebサービスを作る6つのアーキテクチャ上の制約を定義します - true RESTful API 。

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

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

10
Jaider

話す は単なる 情報交換 以上のものです。議定書は実際には話しが起こらないように設計されています。各当事者は、それがプロトコルで指定されているので、彼らの特定の仕事が何であるかを知っています。プロトコルは、可能な動作に何らかの変更を加えることを犠牲にして純粋な情報交換を可能にします。一方、話すことは、一方の当事者が他方の当事者からどのようなさらなる行動をとることができるかを尋ねることを可能にする。暫定的に相手方の状態が変わった可能性があるため、2回同じ質問をして2つの異なる回答を得ることもできます。 話すことはRESTfulなアーキテクチャです 。 Fieldingの論文は、単に communication ではなく、マシンに talk を許可する場合に従うべきアーキテクチャを指定しています。

10
qmckinsey

RESTはRepresentational State Transferを表します。

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

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

安静についての紹介

10
GowriShankar

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

ウィキペディアから ：

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

10
ACV

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

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

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

9
Benoit Essiambre

これについてはどこにも触れられていませんが、 RichardsonのMaturity Model は、Restfulが自分のAPIであるかどうかを実際に判断するための最良の方法の1つです。それについてもっとここに：

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

5
kg11

とは何ですか APIテスト ？

APIテストはプログラミングを利用してAPIへの呼び出しを送信し、歩留まりを取得します。テストは、テスト対象セグメントをブラックボックスと見なします。 APIテストの目的は、適切な実行を確認し、アプリケーションへの調整前の部分の誤った扱いを確認することです。

REST AP​​I

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 AP​​Iプラグインを使用できます。 

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

REST AP​​Iを自動化する手順

5
kkashyap1707

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

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

1
Kürsat Aydinli

リンクされたリソースの例を挙げているこれらの答えは素晴らしいですが、全体像の半分にすぎません。

それで、あなたがウェブサイトをデザインしていると想像してください。あなたは物語を書きます、

配送先住所を選択できるように、郵便番号で住所を検索できるようにしたい

それからあなたはその旅にユーザーを連れて行き、ワークフローで一緒にページをリンクしようとするためにサイトを構築するでしょう。

それらを住所検索に使用した後、住所をクリップボードにコピーしてから配送先住所フォームに戻るようにしたWebサイトデザインは、あまり使用できません。

REST AP​​Iは、マシン間の対話のためにWeb上で当たり前のように取ったパターンを使用します。

郵便番号機能の検索はbase/addresses/{postcode}であるべきではなく、各住所が完全な住所および編集リンクにリンクしていてもコレクションが返されます。 APIコンシューマはアドレスの使い方を推測する必要があります。

代わりに、機能の動機は、旅が最初に戻るようにそれが使用されるフローに組み込まれるべきです。

1 GET /orders/123/shipping

  200 OK { Current shipping details + link to parent + link to address picker }

2  -> GET /orders/123/shipping/addresspicker

      200 OK { Link and form for searching for a postcode }

3   -> GET /orders/123/shipping/addresspicker?postcode=tn11tl

       200 OK { List of addresses each with link to pick it }

4    -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3

        200 OK { Current shipping details + link to parent + link to address picker }

これはユーザーの旅であり、最後にフローが注文に与える影響を見ることができます。

HTTPリクエスト/レスポンスは厳密にはRESTの一部ではありませんが、誰かが非HTTP RESTアプリケーションを見たことはないと思います。

これらのURLは任意の文字セットにすることができます。それらは単なる識別子です。私はそれらを人にとって意味があるのできれいにしました。機械はrelを使用してそれらが何をするのかを解明します。読みやすいhrefには依存しません。

0
Luke Puplett