4

バックエンドが完全な RESTful Web サービスである Web アプリを構築しようとしています。つまり、モデル (ビジネス ロジック) は、HTTP 経由で完全にアクセスできます。例えば：

GET    /api/users/
GET    /api/users/1
POST   /api/users
PUT    /api/users/1
DELETE /api/users/1

CRUD (動詞/アクション) 以外のメソッドを提供する適切な方法は何ですか? これはよりRPC-apiドメインと見なされますか? RESTful API の上で実行するように RPC API を適切に設計するにはどうすればよいでしょうか?

たとえば、ユーザーのパスワードを忘れた場合の方法をエレガントに実装するにはどうすればよいでしょうか。

POST (?) /api/users/1/forgot

アプリケーション (コントローラー/ビュー) は、https 要求 (HMVC など) を使用してモデルとメソッドにアクセスします。認証に最適なものは何ですか? OAuth、HTTPs 経由の基本認証?

これは後でスケーラビリティを確保するための「ベスト プラクティス」ですが、このタスクを設計しすぎていませんか? 典型的な MVC モデルに従って、非常に基本的な API を提供するのが最善でしょうか?

この質問は、主に ASP.NET の MVC 4 (WebAPI) と NodeJS モジュールhttps://github.com/marak/webservice.jsに触発されたものです。

前もって感謝します

4

1 に答える 1

1

私は最近RESTを学び始めました、そして新しいWebサービスを開発するとき、あなたはそれを考慮するために正しいことをしていると思います。

カスタム動詞についての仮定は正しいです。RESTは、一部のアクションを別の方法で処理する必要があり、カスタム動詞が要件に違反していないことを認識しています。サーバーと通信するときはPOSTを使用する必要がありますが、動詞は通常、命令型で記述されます。忘れる代わりに、おそらくリマインドなどを使用します。つまり、結果として何を期待するかを明確に示さずに何が起こったのかを説明するのではなく、何をすべきかについて指示を与える必要があります。

さらに、サービスを構築するための推奨される方法は、ドメイン名にapiを含め、パスから削除することです。私はあなたの特定の例をこのように書きます：

POST /users/1/remind HTTP/1.1
Host: api.myservice.example.com

RESTでのセッション処理は少し注意が必要です。これを行う最もクリーンな方法は、基本アクセス認証を使用して、すべての要求でユーザー名とパスワードで認証することです。しかし、そういうことはめったにないと思います。この質問（およびその受け入れられた回答）を読む必要があります：RESTでのOAuthのトーク​​ンとセッション

編集：あなたの例では、GETリクエストの末尾のスラッシュも削除します。サービスが本当にRESTfulである場合、リソースはとの両方からアクセス可能であるとは想定されていませ/users/ん/users。特定のリソースには、それを指すURLが1つだけある必要があります。スラッシュが付いているURLは、実際にはスラッシュが付いていないURLとは異なります。RESTはそれを削除することを促進し、RESTful Webサービスは両方を受け入れるべきではありません（GETの場合は200 OKで応答することを意味します）が、一方から他方にリダイレクトする場合があります。そうしないと、適切なURL、重複したキャッシュ、しだれ、歯ぎしりについて混乱を招く可能性があります。:)

編集2： Richardson＆RubyによるRESTful Webサービスでは、新しい動詞をパスに入れることをお勧めしません。代わりに、のようなものを追加できます?_method=remind。どちらを選択するかはあなた次第ですが、何を選択するかに関係なく、これらのリクエストをで処理することは想定されていないことに注意してください。Aはリソースを変更してはならず、ユーザーが履歴を前後に閲覧した場合に副作用を引き起こしてはなりません。そうしないと、パスワードを数回再送してしまう可能性があります。代わりに使用してください。GETGETPOST

于 2012-05-20T07:45:39.363 に答える