2

単純なRESTAPIを開発しようとしています。私はまだそれの基本的なアーキテクチャのパラダイムを理解しようとしています。次の点についてサポートが必要です。

  1. 「リソース」は名詞でなければなりませんよね？だから、私は「getUser」ではなく「user」を持つべきですよね？

  2. 私はいくつかのAPIでこのアプローチを見てきました：www.domain.com/users/（リターンリスト）、www.domain.com / users / user（ユーザーに固有の何かをする）。このアプローチは良いですか？

  3. 私が見たほとんどの例では、入力値と出力値は通常、名前と値のペアです（たとえば、color ='red'）。それよりも複雑なものを送信または返送したい場合はどうなりますか？XMLのみを扱うことを余儀なくされていますか？

  4. PUT to / user /メソッドを想定して、システムに新しいユーザーを追加します。入力パラメータの適切な形式は何でしょうか（必要なフィールドは「username」と「password」のみであると想定しています）。ユーザーが成功した場合の良い反応は何でしょうか？ユーザーが失敗した場合（そして説明的なエラーメッセージを返したい場合）はどうなりますか？

  5. 認証と承認への優れたシンプルなアプローチは何ですか？ほとんどのメソッドを、正常に「ログイン」したユーザーに制限したいと思います。呼び出しごとにユーザー名/パスワードを渡しても大丈夫ですか？トークンを渡すことはより安全であると見なされますか（そうであれば、有効期限などの観点からこれをどのように実装する必要がありますか）？

4

2 に答える 2

9

ポイント1については、はい。名詞が必要です。

/usersポイント2については、ユーザーのリストを提供することを期待しています。/users/123私は私に特定のユーザーを与えることを期待しています。

ポイント3の場合、何でも返すことができます。クライアントは必要なものを指定できます。たとえばtext/xml、application/jsonHTTPリクエストヘッダーを使用するなど、そのリクエストにできる限り準拠する必要があります（ただし、処理できるのは、たとえば、text/xml多くの状況で合理的です）。

ポイント4では、新しいユーザーを作成することを期待POSTしています。既存のオブジェクトを更新します。成功またはエラーを報告するには、既存のHTTP成功/エラーコードを使用する必要があります。例：。詳細については、このSOの回答を参照してください。PUT200 OK

于 2010-02-14T14:30:51.400 に答える
6

RESTの最も重要な制約は、ハイパーメディア制約（「アプリケーション状態のエンジンとしてのハイパーテキスト」）です。Webアプリケーションを、クライアントが各状態を要求できるステートマシンと考えてください（例：GET / user / 1）。クライアントがそのような状態を1つ持つと（ユーザーがWebページを見ていると考えてください）、アプリケーションの次の状態に進むためにたどることができるリンク。たとえば、クライアントが詳細状態に移動するためにたどることができる「ユーザー状態」からのリンクがある場合があります。

このようにして、サーバーは、実行時に一度に1つの状態でアプリケーションのステートマシンをクライアントに提示します。賢いこと：ステートマシンは実行時に一度に状態で検出されるため、サーバーは実行時にステートマシンを動的に変更できます。

そうは言っても...

1.リソースは基本的に、クライアントに提示するアプリケーションの状態を表します。多くの場合、はドメインオブジェクト（ユーザーなど）と厳密に一致しますが、それらに提供する表現は、単にシリアル化されたドメインオブジェクトではなく、Webアプリケーションの状態であることを理解してください。

GET / users/123の観点から考えるのは問題ありません。URI内にアクションを配置しないでください。有害ではありませんが（不透明な文字列です）、控えめに言っても混乱します。

ブライアンが言ったように。Atom Publishing Protocol RFC（5023）は、作成/読み取り/更新のサイクルを非常によく説明しているため、ご覧になることをお勧めします。

on3.ドキュメント指向のメッセージに焦点を当てます。メディアタイプは、アプリケーションのセマンティクスを（完全に）提供するため、RESTの重要な部分です。多くの場合暗黙的なスキーマの周りでクライアントとサーバーを結合するため、application/xmlやapplication/jsonなどのジェネリック型は使用しないでください。ニーズに合うものがない場合は、独自のタイプを作成してください。

たぶんあなたは私がUBLを使って一緒にハッキングしている例に興味があります：http ：//www.nordsc.com/blog/？cat = 13

on 4.通常、作成にはPOST /users/を使用します。RFC5023を見てください-これはそれを明らかにします。わかりやすいスペックです。

on 5.セッション（ステートフルサーバー）を使用できず、RESTfulになることができないため、すべてのリクエストでクレデンシャルを送信する必要があります。さまざまなHTTP認証スキームがすでにそれを処理しています。HTTP Authorizationヘッダーには、キャッシュに対して特別に指定されたセマンティクスがあるため、キャッシュに関しても重要です（パブリックキャッシュはありません）。クレデンシャルをCookieに詰め込むと、その重要な部分が失われます。

すべてのHTTPステータスコードには、特定のアプリケーションセマンティクスがあります。それらを使用し、HTTPを介して独自のエラーセマンティクスをトンネリングしないでください。

詳細については、＃rest IRCにアクセスするか、Yahooのrest-discussに参加してください。

1月

于 2010-02-14T15:00:10.700 に答える