1

現在、かなり標準的な REST API を使用したサービスがあります。

show: GET /users/1
update: PUT /users/1

...そして、同じ規則に従ういくつかの has_many 関係:

show: GET /users/1/friends/1
update: PUT /users/1/friends/1

ただし、設定を処理するための EAV テーブルもあり (申し訳ありませんが、この部分は変更されません)、has_one 関係として機能するように設定されています。初めの：

user.settings # returns {:sound => true, :tutorials => true}
user.update_settings # expects {:sound => false}

ローカルではうまく機能しますが、他のルートが機能する方法を表す ID はありません。代わりに、ルートは次のように設定できます。

show: GET /users/1/settings
update: PUT /users/1/settings

これはこれを処理する通常の方法ですか、それとも私が知らない他の規則がありますか?

4

1 に答える 1

1

設定にアクセスするのに Id が必要ないのであれば、それをコレクションの属性として扱ってみませんか? 内部的には同じです/users/:id/settings。エンドポイントを閉じるだけです。そしてGET、UPDATE設定を変更するユーザー リソース。ユーザーは次のようになります。

{ "id" : 12,
 "settings": {
...
 }
}

属性を設定することを考えると、エンポイントは文法的に正しくないようです。ユーザーの年齢に関して同じ質問をしたとします。/user/:id/age エンドポイントを開きますか? 設定がより多くの属性を持っているということだけですか？どこで停止しますか？繰り返しになりますが、概念の問題であり、何よりも一貫性です。

しかし、レスタファリアンにならないでください。あなたのアプローチも良いです。私にとっては、開発者が例外を説明するために大量のドキュメントを書く必要がないように、一貫性の問題です。したがって、残りの部分に何が最も適しているかを考慮して選択してください（私は私の提案に行きます）.

実用的に！

于 2013-05-23T22:57:05.717 に答える