問題タブ [hateoas]

私は今RESTで遊んでいて、すべての概念を正しくするためにHATEOASを適切に実装していると思いました。

application/vnd[...]+xmlそのために、独自のメディア タイプ (および)を作成したいと考えていますapplication/vnd[...]+json。

最初の質問:メディア タイプは、サーバーとクライアント間の契約を定義しますか?

メディア タイプによってメッセージ形式が定義されるため、新しいメディア タイプに合わせて XML スキーマと JSON スキーマを追加する必要があります (これにより、REST クライアントはメッセージに何が入ってきて、何を送り返すかを知ることができます)。

私はウェブでいくつかの調査を行いましたが、これを行う方法の詳細が欠落しています。網羅的な仕様/ドキュメントを作成するだけですか、それとも実装するための技術的な手順がいくつかありますか? (IANAに登録しなくてもいいですよね?)

完全に機能する新しいapplication/vndメディア タイプを作成するにはどうすればよいですか? また、クライアントが適切に使用できるようにするには、何に注意する必要がありますか?

HATEOAS 原則「クライアントは、サーバーによってハイパーメディア内で動的に識別されるアクションによってのみ状態遷移を行う」

今、私は単語動的に問題を抱えていますが、それはそこで最も重要な単語の 1 つだと思います。

API でパラメーターの 1 つをオプションから必須に変更した場合、クライアントを修正する必要があります。そうしないと、リクエストが失敗します。

要するに、HATEOAS が行うことは、サーバー側の開発者に、API を使用するすべてのクライアントを犠牲にして、API を自由に変更できる極端な自由を与えることだけです。

私はこれを言っているのは正しいですか、それともサーバーが採用しなければならないJSON以外のバージョニングや他のメディアタイプのようなものを見逃していますか?

私は（ほぼ）「ウィザード」のWebベースのプロジェクトを書いています。基本アーキテクチャは、HATOASアプローチに従うことを目的としたWebクライアントによって消費されるRestfulサービスです。それほど軽量ではないプロジェクトなので、プロジェクトを3つの異なるSinglePageApplicationsに分割することを考えていました。あなたたちにとって、それは良い考えですか？もしそうなら、ページ間でパラメータを渡すための最良のアプローチはどれですか？例えば。1つのページで「リソースA」を管理し、基本的なCRUD操作を実行してから、次のステップでそのうちの1つを選択します。analisysは、「リソースA」に関連するオブジェクトに基づいているため、少なくとも「リソースA」IDと、場合によっては他のいくつかのパラメーターを渡す必要があります。ありがとう

RESTful HATEOAS API を作成しています。GET、POST、および PUT する必要がある複合エンティティがあります。GET 部分は簡単で、多くの例があります。応答には、エンティティのプリミティブ属性と、ネストされたエンティティへのリンクが含まれます。例えば：

アカウントを作成または変更するときに問題が発生します。アカウントを accountType に関連付ける必要があります。次のような POST リクエストを送信できますが、{"firstName":"Michael","lastName":"Jackson","balance":300.0,"accountTypeId":5}
それは HATEOAS パラダイムを壊してしまいます。POST/PUT 複合エンティティのベスト プラクティスは何ですか?

こんにちは私はジャージー入門ガイドを通過しています。

第6章では、@Refアノテーションを使用してリソースのURIを挿入します。私は例に従いましたが、私のURIは常にnullです。

プログラムでにを追加com.sun.jersey.server.linking.LinkFilterするにはどうすればよいですか？com.sun.jersey.spi.container.ContainerResponseFiltersweb.xmlを使用した例はすでにたくさんあります。

ありがとう！

FSCHateoasBundle を使用して、API 出力にリンクを追加しようとしています。

ドキュメントには、注釈または yaml を使用して関係を構成する可能性について言及されていますが、yaml 構成を配置する場所と構成方法がわかりません。文書化された注釈は正常に機能します。誰か例がありますか？

私がやろうとしているのは、JMSSerializer で使用される構成ファイルに「関係」セクションを追加することです。FSCHateoasBundle 用に個別の構成ファイルを使用する必要がありますか?

私は、リソースがかなり相互に関連しているRESTフルAPIを使用しています。リソースは相互に参照し、これらの参照は作成または削除される場合があります。リソースがハイパーリンクを使用して相互に参照するときに、リソースの関連付けをサポートする方法が少しわかりません。

簡単な例は、AとBの2つのリソースで続きます。

現在、AはドキュメントにBを含めていませんが、Bをリンクしています。ハイパーメディアを使用すると、次のようになります。

ユーザーがAのリストにあるB参照の1つを追加または削除したい場合、ハイパーリンクの存在を考慮して、どのように行うのですか？ユーザーが1回のPUT操作でAリソース全体を更新できるようにしたいのですが、出力にはBのどの値が必要かを示すものはありません。ユーザーが次のようなコンテンツでPUTを実行することは私には理にかなっています。

次のように（応答で）更新されたリソースを受け取ります。

私の懸念は、ユーザーがリソースAを更新するときにリソースに何を含めるかを必ずしも知っているとは限らないことlist_bです。

あるリソースから別のリソースへのハイパーリンクを処理する場合、作成と更新はどのように機能する必要がありますか？クライアントはリンクの一部（id）を更新することを許可する必要がありますか、それともリンクの両方の部分を更新する必要がありますか？

注：別のアプローチがリソースAのサブURLを公開する可能性があることを知っています。これはlist_b、HTTP経由で操作可能なリソースとして公開できます（クライアントがリストリソース自体でPOST、PUT、およびDELETEを使用できるようにします）。ただし、Aに他のリソースタイプへの複数の参照が含まれている場合、これはあまり合理的ではないようです。別のフィールドを参照する各フィールドには、サブURLが必要になる可能性があります。これは、10以上のフィールドがある場合、扱いにくく、リソースを更新するために複数のHTTPリクエストを必要とします。

Web APIプロジェクトを開始することを検討していて、（2つの？）フレームワークのどちらを使用すれば、摩擦を最小限に抑えてリチャードソン成熟度モデルをさらに進めることができるのでしょうか。

おそらくHOWTOへのリンクですか？