4

複数のハイパーメディア タイプと認証をサポートする REST フレームワークに取り組んでいます。処理方法がよくわからないのは、リソース内の機密値です。たとえば、API にユーザー管理を含める場合、パスワード用のフィールドがあることをクライアントに公開する方法が必要になりますが、実際のパスワード ハッシュは表示されません。クレジットカードでも同じです。そうしないと、フィールドの知識が範囲外になり、HATEOASが壊れてしまうため、ハイパーメディアの制約に違反します。

私が遭遇した実際のユースケースは次のとおりです。

プロジェクトは、他の人が彼らを雇うことができるように彼らを紹介する人々のディレクトリです. ユーザーには、プロファイルを持つユーザーと持たないユーザーの 2 種類があります。リソース周辺の設計は/users/{userid}ユーザー向けであり、ユーザー/users/{userid}/profile/profile/{profileid}のリンクが含まれているため、クライアントはユーザーの名前などを取得できます。また、ユーザーは にクレジット カードを保存できます/users/{userid}/creditcards/{creditcardid}

ユーザーのプロファイルを表示するには、名前などにアクセスできるユーザー リソースも必要です。私たちが望んでいないのは、ユーザー リソースやクレジット カード リンクでユーザーのパスワードを公開することです。問題なくクレジット カード リンクを非表示にできると思いますが、パスワード フィールドについてはわかりません。許可されたユーザーに対してのみ公開する必要がありますが、他のユーザー モデルでは公開しないでください。認証および承認されていない限り、ユーザーに対してのみGET許可されることに注意してください。

これを強調する奇妙なエッジケースの 1 つは、部分的にアクセスして変更できるオブジェクトです。あなたが、ユーザーの名前とアドレスを変更するアクセス権を持っていたが、パスワードを変更できなかった低レベルの管理者だったとします。アクセス権がないため、パスワード フィールドを公開できません。PUTすべてのフィールドを持っていないリソースに対してどのようにすればよいですか? そのような場合に使用する必要がPATCHありますか?

TL;DR: REST API でフィールドを適切に非表示/公開し、ハイパーメディアの制約に従うにはどうすればよいですか?

4

1 に答える 1

0

まず、機密情報がある場合は常に SSL を使用します。SSL を使用すると、リクエストは暗号化されます。URL もネットワーク上で暗号化されます。ただし、同じ URL がクリア テキストでログに記録される可能性がある場所は他にもたくさんあるため (プロキシ サーバー、ロード バランサー、DNS サーバーなど)、機密情報を URL に含めないことが重要です。

では、それは REST API にとって何を意味するのでしょうか? まず第一に、ID に機密情報を使用しないでください。クレジット カード番号は一意の場合がありますが、それをカードの識別子として使用しないでください。

また、リソースを取得するときにパスワードを返さないでください。このタイプの情報はサーバーでフィルタリングする必要があります。リクエスト本文で受け入れることはできますが、レスポンス本文で送り返してはいけません。

他の奇妙なエッジケースでは、PATCH はまだ標準ではありません。1 つになるまでは、POST を使用してリソースの部分的な更新を行っている人をたくさん見てきました。POST は冪等である必要はないので、実際には非常に理にかなっています。したがって、POST は部分的な更新であり、PUT は特定の ID での作成または置換です。いいね?

HATEOAS に関する Les Hazlewood の講演をまだご覧になっていない場合は、ぜひご覧になることをお勧めします。ベストプラクティスのかなり良い概要を提供します。

http://www.youtube.com/watch?v=mZ8_QgJ5mbs

于 2013-10-03T21:54:16.523 に答える