REST API設計：POST（暗黙のuserId）とPUT（explicit userId）
GET /newsのようなAPIの一部のルートでは、ユーザーはそれらに関連するニュースのみを必要とすると想定するため、userIdは認証情報から暗黙的に取得されます。
ただし、設計中のAPIの一部のルートは「ユーザー」リソースを変更します。つまり、一部のアカウント情報を変更します。たとえば、ユーザーはアカウントの名前を変更したい場合があります。私はそれをできた
POST /users/name
または
PUT /users/:userId/name
1）この二分法は一般に正しいですか（正しい意味は、ほとんどのREST APIがこの方法で設計されることを意味します）？ PUTがPOSTが認証情報から取得する明示的なuserIdを使用するという考え
2）上記に当てはまる場合、「modifying-account-info」タイプのルートの場合、どのスタイルがより意味がありますか？いいえの場合、何を提案しますか？
両方の方法で設計された優れたAPIを見てきました。一方で、認証でuserIdを提供するand URLは冗長に見えます。
一方、あるユーザーが別のユーザーのパブリックデータを確認する方法がある場合、または取得する必要があるクライアントで同じまたは同様のAPIを使用している場合は、URLに明示的なIDを含める方が一貫している可能性があります。多くのユーザーのためのデータ。これにより、冗長であるかどうかにかかわらず、常にURLにuserIdを指定できます。
余談ですが、URLで「私」という単語を使用して認証済みユーザーを参照できるAPIも見ました。
基本的に、1つに2つの異なる質問があります。それらを簡略化して言い換えましょう：
1. userIdが認証情報として1回、データオブジェクトの一部として1回ある場合、どちらを使用する必要がありますか？
それらのどれも勝つべきではありません。これらは2つの異なるuserIdであり、1つはアクションを実行するユーザー、もう1つはアクションの主体としてのデータオブジェクトユーザーです。管理者が別のユーザーの名前を変更することを考えてください。通常のユーザーの場合、この2つのIDを比較し、異なる場合はエラーステータスコードを返す必要があります。
2.場所自体を変更するリソースの場所へのAPI呼び出しを設計するにはどうすればよいですか？例：PUTから/users/{name}はnameを変更する可能性があります。
だからあなたはuserIdを持っています。 userIdは変わらないと思います。したがって、この場所をPUTに使用して、ユーザーを更新します。便宜上、場所にレスポンスリダイレクトを提供できます/users/{name}リソースの対応する永続的な場所に。
きみの GET /news基本的に、認証情報の背後で作業しているリソースを隠します（通常、認証情報はsessionIdを使用してサーバーに転送されます）。これはRESTfulではありません。URLで使用しているリソースを明示的に定義する必要があるためです。
正しいバージョンは次のとおりです。
GET /news?userId=:userId
この場合でも、認証情報を使用してリクエストを検証/承認しますが、RESTの観点からは問題ありません。
このルールの唯一の例外は、POSTがサーバーでキーが生成されている間に新しいエンティティを作成する場合です-この場合、まだ知らないため、IDを省略します。いくつかの欠点（非べき等）があるため、クライアント生成キーでPUTを使用する方が優れています。