19

新しいリソースのコンテンツを応答本文に入れ、新しいリソースの URL を Location HTTP 応答ヘッダーに入れることで、POST 要求に応答する API をまとめました。

サンプルリクエスト:

POST /api/v1/widgets HTTP/1.1
Content-type: application/json;
Accept: application/json;

{
    "name": "hugo@example.com",
    "price": "10",
}

応答例:

HTTP 201 Created
Location: http://example.com/api/v1/widgets/123456

{
    'widget': 
    {
        'id': "123456",
        'created': "2012-06-22T12:43:37+0100",
        'name': "hugo@example.com",
        'price': "10",
    },
}

応答の本文にも URL を含める必要があるという問題が提起されました。これに関するベストプラクティスはありますか?

4

2 に答える 2

14

新しく作成されたリソースの場所 (URL) を本文に入れないのには理由があります。URL は、サービス コンシューマーとサービス間のメッセージ対話に必要なメタデータであり、「ビジネス データ」ではありません。「メッセージング メタデータ」と呼ばれる SOA デザイン パターンがあり、URL、セキュリティ資格情報、相関識別子、トランザクション ID、およびその他のメッセージングおよび構成コンテキスト データを、メッセージの本文ではなくヘッダーに配置する必要があることを示唆しています。実際、http はすでにそのための標準ヘッダー Location を提供しています。

OTOH、REST サービスが HATEOAS を使用している場合、応答には、消費者が動的にバインドして呼び出すために提供する操作への直接リンクである 1 つ以上の URL が含まれる場合があります。

ヘッダーとボディの両方に URL を含めることは、最悪の解決策だと思います。冗長なデータは、長期的には不整合になりがちです。

于 2014-11-12T12:33:46.810 に答える
11

私はそれをヘッダーに入れます（ Location: http://blah.blah.com/blahとして）。必要に応じて（送信する適切な形式で）、それを体に入れることもできますが、それは不適切ではありません.

atompub REST APIは、通常、優れた REST APIの優れたリファレンスです。彼らはそれを両方に入れました。

HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/edit/first-post.atom
ETag: "c180de84f991g8"  

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name></author>
  <content>Some text.</content>
  <link rel="edit"
      href="http://example.org/edit/first-post.atom"/>
</entry>
于 2012-06-22T15:42:51.363 に答える