問題タブ [hypermedia]

RESTful API メソッドがあるとします。

address別のリソースへのリンクがあることがわかります。

address_idそのリソースのを解決するには、サーバーは次のことを行う必要があります。

1. URL を分割し、ルートの「id」部分を特定します

2. address_idそのリンクされたリソースを取得するために、それ自体にcurlリクエストを行うことさえできますか?

RESTful API が別のリソースへの暗黙的なリンクを含む表現を受け入れることを許可することに不利な点はありますか?

これを説明するために、次の 2 つのリソースがあるとします。

個人には、 に加えて一意の識別子がidあり、これがemailです。

次の対話を許可することに不利な点はありますか?

peopleサーバーは電子メール フィールドが一意であることを認識しているため、リソースの識別に使用できます。それはその人との関連付けを作成します。

これを許可する理由は、最初にリソースの URI を検索する必要がない API クライアントで簡単にするためです。

対照的に、私は確かにこのタイプの呼び出しを許可します:

私はまだこの RESTFUL に慣れていないため、ブログなどを読んでいるので許してください...そして、それらはすべて異なる実装/ガイドラインを持っています。実際のガイドラインは、ハイパーメディアとは何かを指定するリチャードソン成熟度モデルだけです。

ハイパーメディア設計の利点は、ルート URL を介してマシン/ユーザーの対話を駆動する注釈とのリンクを持つことであり、リンクが変更されたときのように進化可能であり、べき等/安全な http 動詞などでキャッシュを強化することです...

私は RESTFUL API Web サービスを設計しようとしています。HAL、Collection+Json、Siren などの汎用メディア タイプを使用する予定です。今...

一般的なメディア タイプを使用すると、ペイロード、データ構造、または DTO オブジェクトなど、「多くの申請者を持つアプリケーション モデルと多くのアドレスを持つモデルなど」のようになります。

1) データ構造定義をどこかに指定する必要がありますか? または何らかのフォーム テンプレートですか。そのデータの定義を人間が読める形式で「someurl / doc？またはjsonスキーマのようなものを使用する必要がありますか？」のような例を見てきました。

2）私が見たいくつかの例では、データ項目を vcard/foaf などからのリンクのタイプで装飾しました。"名前": " http://xmlns.com/foaf/0.1/name ". どういう意味ですか？私が見るいくつかの例には、名前オブジェクトなどを説明するための someurl/doc#name への参照が似ています...

3) Application Model のペイロードが変わると、コントラクトのインタープリターが変わるということですか? したがって、SOAP のように、すべてのクライアントが以前と同じように壊れますか?

4) もう 1 つの選択肢として、実際の構造を形成する Name,Value,Prompt を持つコレクション + json アイテム オブジェクトのように、進化可能なアイテム構造を持つことができると思います。これにより、それを消費するクライアント側で最小限のコントラクトの変更が行われます。

オブジェクトをどのように設計すべきかについてアドバイスをお願いします。基本的に、質問を簡単にするために、複数のアドレスを持つ複数の申請者を持つアプリケーションオブジェクトがあると言います。

ジョシュ

私たちが開発しようとしている API の Layer3/HATEOS/RESTful/HAL 全体を調査しています。

これらすべてのリンクによって肥大化する可能性のあるデータのリストを公開します。リンクをテンプレート化するのはアイデアではありませんか?これは何と呼ばれますか? それについての言及が見つからないようです。それが良いアプローチではない場合、なぜですか?

仮想の休日検索 API を例にとると、エントリ ポイントは目的地と出発空港のリストを提供し、ユーザーはどちらか一方を使用して検索を開始できます。

次のようなものは、より効率的なアプローチでしょうか? (大まかに HAL に基づく) そして、そうでない場合はなぜですか?

}

ハイパーメディア ベースの API を構築しようとしています。物事はうまくいっているようです。フェッチ/books/isbn/12313441213すると、次のようなものが得られます。

これで、このリソースから著者をたどることができます。フェッチする/books/by/author/id/18と、次のようなものが得られます。

これも私にとってはうまくいっているようです。この uri テンプレート化の方法が良いかどうかにかかわらず、私の質問は、このようなリンクをたどるのがどれほど実用的かということです。

リソースの完全な詳細 (作成者の詳細を含む) が必要であることを考慮すると、サーバーに対して少なくとも 3 回の呼び出しを行う必要があります。繰り返しになりますが、コレクションについては、サーバーに対して大量の呼び出しを行う必要があります。はい、ここでリソースの拡張を利用できるかもしれませんが、すべてのクライアントが時間内に拡張されたリソースを使用するため、ハイパーメディア リンクを使用する必要はありません。

クライアントがリンクをトラバースできるようにすることで、多くのことが得られていることを理解しています (つまり、クライアントがリレーション ベースのリソース ディスカバリを構築する場合、API を変更しても最小限の影響を受けるか、リソース エンドポイント自体から最新のスキーマを取得する必要があります。等）。繰り返しになりますが、このアプローチの実用性、またはこのアプローチのパフォーマンスは、システムを殺します。

ハイパーメディア api の設計で何かを得ていないか、ハイパーメディア api は素晴らしいように聞こえますが、それは単なる理論的なアイデアであり、実用的なアイデアではないようです。

これについて何か考えはありますか？

REST インターフェースの要件の 1 つは、各リソースが固有のフィールド (主要な識別子を除く) によって識別可能であることです。これは、データの一括インポートを処理できるようにしたいためです。この場合、クライアントはシステムが生成したプライマリ識別子を知ることができません。

これは、一意のフィールドでリソースを参照できる必要があることを意味します。主キーを使用すると、読み取りリクエストは次のようになります。

その顧客に関連する注文を取得する

ここで、customer の 2 つのフィールド name ("foo") と businessId ("bar") で一意に識別されると仮定します。そのため、この顧客の注文を取得するために、次の URI を思い付きました。

しかし、これが一意のフィールドを介してアクセスされるリソースであることを識別するための別のパスがあるのは好きではありません。主キーの代わりに一意のフィールドを使用して、RESTful な方法で上記のクエリをどのように構成しますか?

さらに、注文は次のようになります。

インターフェイスと通信するときに、クライアントが hrefまたはキーを交換可能に指定できるようにすることに関する問題はありますか?

SailsJS を使用して HTML5 ハイパーメディア (HATEOAS) API を実装する良い例はありますか? もしそうでなければ、なぜですか？