5

私は、RESTful API 用のカスタム メディア タイプを設計している最中であり、いくつかの「標準」リンク関係のタイプとセマンティックな意味を調査して、私の設計にある程度の操縦を与えました。

問題を示すために、標準の読み取り、変更、削除メソッドを実行できるリソースがあり、GET、PUT、および DELETE の HTTP イディオムをそれぞれ使用してこれらのメソッドを実装するとします。

RFC5023で定義されているように、「編集」リンク関係 ( IANA リンク レジストリから) を合理的に (再) 使用できます。

"..."edit" の値は、href 属性の値が編集可能なメンバー エントリの IRI であることを指定します。atom:entry 内に表示される場合、href IRI を使用してリソースを取得、更新、および削除できます。そのエントリによって表される....」

このようにして、ユーザーエージェントは、「編集」関係を持つリンクがリソースの GET、PUT、および DELETE を許可することを理解できます。

ただし、ここに問題があります。リソースが GET 操作と DELETE 操作のみをサポートするようにリソースの状態が編集された場合、「編集」関係は正確ではなくなります。

精度を維持するために、i) オプション A: GET と DELETE のみをサポートする別の (複合) リンク関係を指定するか、または ii) オプション B: 可能な状態転送ごとに個別のリンクを指定し、適切なリンクを使用して示す必要があります。許可された状態遷移。後者のアプローチは正確ですが、過度に冗長に見えます。

別の方法として、(オプション C) 「編集」関係をそのままにして、精度の欠如を受け入れることもできます。つまり、リンクは GET、PUT、DELETE セマンティクスを伝達しますが、PUT を試みるユーザー エージェントは HTTP エラーに遭遇します。 405 - メソッドは許可されていません。ただし、サポートされていない状態遷移をクライアントに暗示するため、このアプローチにも満足していません。

要約すると、問題は、リンク関係の一般性と精度のバランスをとる最も賢明な方法は何かということです。

4

3 に答える 3

2

いくつかの深刻な調査の後、私は間違った問題を解決しようとしていると結論付けました。リンク関係の定義における HTTP 動詞の粒度に関心を持つのではなく、より洗練された質問は、「HTTP イディオム (動詞) をリンク関係に統合する必要がありますか?」です。

Link Relations（REST用）のやり方を参考にAtomPubを使っていたのですが、これは間違いでした。Roy Fielding は、AtomPub のメール アーカイブで、(REST 用語で) 「編集」へのアプローチは間違っているとアドバイスし、不要であると結論付けています。この議論は、そのようなプロパティを伝達するための他の (HTTP) メカニズムが存在することを示唆しており、したがって、それらは 'rel' 属性には存在しません。

他のメカニズムはメールアーカイブで明示されていませんが、次のオプションが含まれていると思われます:

  1. ユーザーエージェントに応答 (2xx または 4xx) を試して調べさせるか、または
  2. OPTIONS を使用して、リソースに許可された操作を要求するか、または
  3. 成功した GET リクエストに「Allow」ヘッダーを含めて、許可されたリソース操作をユーザー エージェントに伝えます。

興味深いことに、Roy は「Allow」ヘッダーを「ハイパーテキストの形式」と見なしています。

要約すると、私自身の質問に対する答えは次のとおりです。

" HTTP 操作を 'rel' の意味に混同しないでください"

と

" (提供された) HTTP メカニズムを使用して、許可されたリソース操作を決定します"

編集：これらのルールを少し曲げる必要があるデータシンクとしての POST の特別な使用法がいくつかあることを追加する必要がありますが、それらは特殊なケースです。

于 2012-05-15T20:06:26.213 に答える
1

WRML仕様は、各「リンク」オブジェクトが rel プロパティを持つことができるアプローチを採用しています。

GET /dogs/1
{
    "links" : {
        "self" : {
            "href" : "http://api.example.com/dogs/1
            "rel" : "http://api.example.com/relations/self"
        }
    }
}

そして、クライアントはrel urlをたどることができます

GET /relations/self
{
   "name" : "self"
   "description" : " A reference back to the same object you are currently interacting with" 
   "method" : "GET"
}

仕様では、各 rel に正確に 1 つのメソッドを指定することを推奨しています。これには、クライアントに対して何をすべきかを明確に示すことができるという利点があり、必要とされる範囲外の知識の量を制限します。特定の「rel」が複数の HTTP メソッドを提供すると言うことに何らかの価値があると思うので、私は個人的にこれについて行ったり来たりしています。犬の飼い主のリンクを想像してください

GET /dogs/1
{
    "links" : {
        "self" : {
            "href" : "http://api.example.com/dogs/1
            "rel" : "http://api.example.com/relations/self"
        }
        "owner" : {
            "href" : "http://api.example.com/owner/1
            "rel" : "http://api.example.com/relations/owner"
        }
    }
}

GET と PUT はどちらも有効なアクションであるため、「所有者」に GET と PUT を暗示させるとよいでしょう。これに対する反論は、更新を行う前に常に GET を実行する必要があるため、リソースを取得する前にその情報を提供することの価値は悪い形です。

だから、私はオプションBに投票すると言っていると思います.

于 2012-02-28T15:02:55.417 に答える
0

もう 1 つのオプションは、「編集」関係を離れ、リソースに対して現在実行できることを知りたいコンシューマーが OPTIONS HTTP メソッドでリクエストを作成できるようにすることです。サーバーは、それを示すためにAllowヘッダーを含むレスポンスを返すことができます。リソースの現在の状態で許可されているメソッド。

追加のリクエストなしで PUT 操作を利用できるわけではありませんが、かなり「クリーン」であり、標準のリレーションと HTTP メカニズムを使用できます。

于 2012-02-28T02:23:56.547 に答える