0

提供された認証 (ログイン) に基づいて Account リソースを提供する API があります。ユーザーは 1 つのアカウントしか持つことができず、自分のアカウントのみを表示でき、他のユーザーのアカウントは表示できないため、この API は基本的にすべてのケースで単一のリソース API になります。

簡単にするために、URL の下にこのリソースがaccounts/あり、アクセスaccounts/?username=dude&password=veryhardするとアカウント データが取得されます (認証を提供しない場合は 403 が返されます)。

これがRESTfulなのかどうか疑問に思います。また、アカウント情報を更新できるはずで、PUT が適切かどうか疑問に思います。私の知る限り、リソースの一意の URI で PUT を実行する必要があります。さて、これはリソースの一意の URI ですか? 通常、アカウントの URIは、アカウント ID はaccounts/3515/whereのようになります。3515ただし、ユーザーは自分のアカウント ID を知りません。また、ユーザー名とパスワードの代わりに、トークン (のような) も使用できるようにする必要がありますaccounts/?token=d3r90jfhda139hg。それで、同じリソースを指す 2 つの URL を取得しましたが、これも RESTful URI としてはあまり美しくありませんね。

では、最も RESTful なソ​​リューションは何でしょうか? または、このRESTfulを行うべきではありませんか?

4

2 に答える 2

2

REST 純粋主義者は/accounts/、コレクションを指定する必要があるため、単一のアカウントを取得するために を使用することは悪い習慣であると考えるでしょう。代わりに、ID と間違えられないキーを検討してください。たとえば、ID が UUID の場合、「me」などのトークンを使用して URL を/accounts/me. これには、たとえば、ユーザーをリストする必要がある場合や、同じ API を使用する管理システムがある場合など、後で別のアカウント情報を取得したい場合に、簡単に拡張できるという利点があります。

URL にユーザー名とパスワードを入れることも、純粋な REST ではありません。クエリ パラメータは、取得するリソースに直接関連している必要があります。通常、返されるリソースをフィルタリングおよび制限します。代わりに、暗号化された (HTTPS) 接続を介した HTTP Basic 認証のようなものを使用して、認証/承認システムとリソース システムを分離することを真剣に検討する必要があります。トークン システムを使用する場合は、oauth または hawk を参照してください。

最後に、はい、PUT を使用する場合は、完全なリソース識別子を指定する必要があります。システムがデータを更新する前に読み取ることは非常に一般的であるため、ID がなくても問題はありません。これは、以前の GET の一部として返されるためです。

于 2013-09-24T16:29:53.730 に答える