14

したがって、RESTful API の一般的なパターンは、関連するオブジェクトを取得するために使用できるリンクが埋め込まれた単一のオブジェクトを返すことです。しかし、便宜上、オブジェクト グラフのチャンク全体を一度に引き戻したい場合があります。

たとえば、customers、orders、およびreturnsを持つ店舗アプリケーションがあるとします。顧客 ID 12345 の個人情報、すべての注文、およびすべての返品を一緒に表示したいと考えています (おそらく、常に注文を返品し、顧客の個人情報を返品するとは限りません)。

これを行う純粋な RESTful な方法は、次のようなものです。

  1. GET /
    • 顧客を照会するものを含む、リンク テンプレートのリストを返します
  2. GET /customers/12345( のリンク テンプレートに基づく/)
    • お客様の個人情報を返します
    • この顧客の注文と返品を取得するリンクを返します
  3. GET /orders?customerId=12345（/customers/12345回答より）
    • 顧客 12345 の注文を取得します
  4. GET /returns?customerId=12345（/customers/12345回答より）
    • 顧客 12345 の返品を取得します

customersしかし、 URI を取得したら、これをすべて 1 つのクエリで取得できると便利です。複数のリクエストを作成する代わりに、一部またはすべてのリンクをトランスクルージョンしたい、この種の便利なクエリのベスト プラクティスはありますか? 私は次のようなことを考えています：

GET /customers/12345?include=orders,returns

しかし、人々がこれを行っている方法がある場合、私は単に何かをでっち上げたくはありません。

(FWIW、私はストアを構築していないので、これらがモデルに適したオブジェクトであるかどうか、または実際の製品にどのようにドリルダウンするかなどについて、口論しないでください。)

追加の更新: HALでは、これらは「埋め込みリソース」と呼ばれるように見えますが、示されている例では、埋め込むリソースを選択する方法がないようです。クエリ パラメータとして使用して、上記のような内容を示唆するブログ投稿を見つけました。embed

GET /ticket/12?embed=customer.name,assigned_user

これは標準的または準標準的な慣行ですか、それとも 1 人のブロガーがでっち上げたものですか?

4

1 に答える 1

1

Being that the semantics of these types of parameters would have to be documented for each link relation that supported them and that this is more-or-less something you'd have to code to, I don't know that there's anything to gain by having a a standard way of expressing this. The URL structure is more likely to be driven by what's easiest or most prudent for the server to return rather than any particular standard or best practice.

That said, if you're looking for inspiration, you could check out what OData is doing with the $expand parameter and model your link relation from that. Keep in mind that you should still clearly define the contract of your relation, otherwise client programmers may see an OData-like convention and assume (wrongly) that your app is fully OData compliant and will behave like one.

于 2013-11-16T04:46:31.737 に答える