11

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

{
 "id":"2",
 "firstName":"Brad",
 "lastName":"Pitt",
 "balance":1234.5,
 "transactions":"http://localhost:8080/jersey-poc/api/v1.1/account/1/transactions",
 "self":"http://localhost:8080/api/v1.1/account/1",
 "accountType":"http://localhost:8080/api/v1.1/account/1/accountType"
}

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

4

1 に答える 1

3

HATEOAS に反するペイロードについては特に何もありません。唯一の本当の問題は、accountTypeIdがあまり見つけられないことです。(マジック ID は、短い説明文字列にマップされた方が常に良いです。それらは列挙型のようなものと考えてください。) HATEOAS モデルに取り組む際に覚えておくべき重要なことの 1 つは、ユーザーが POST するエンティティがそうである必要がないということです。リソースを作成する正確なエンティティ。変更、注釈、翻訳ができます。概念的には同じはずですが、それは同一であることとはまったく異なります。(ID と作成タイムスタンプを追加することは、拡張が完全に合理的であることを示す優れた例です。)

私には、あなたの本当の問題は、クライアントが POST を実行するときに送信する必要がある情報と、POST を実行するときにその情報を送信する必要があることをクライアントに伝える方法を再検討する必要があることのように思えます。私自身、ここでのアップロードに XML を使用するのが非常に好きです。なぜなら、POST ペイロードが特定のスキーマに準拠する必要があることをクライアントに簡単に伝えることができるからです (そして、XML スキーマと RELAX NG は両方とも、制約を説明するのに十分なほど豊富です)。それが唯一の方法ではないと確信しています。

于 2013-02-14T09:40:39.107 に答える