web-dev-qa-db-ja.com

/ loginまたは/ registerリソースをRESTfulに設計しますか？

私はWebアプリを設計していましたが、RESTful WebサービスとしてどのようにAPIを設計すべきかを考えるために立ち止まりました。今のところ、私のURIのほとんどは汎用であり、さまざまなWebアプリに適用される可能性があります。

GET  /logout   // destroys session and redirects to /
GET  /login    // gets the webpage that has the login form
POST /login    // authenticates credentials against database and either redirects home with a new session or redirects back to /login
GET  /register // gets the webpage that has the registration form
POST /register // records the entered information into database as a new /user/xxx
GET  /user/xxx // gets and renders current user data in a profile view
POST /user/xxx // updates new information about user

SOとgoogleをいじくり回した後、ここでかなり間違っていると感じています。

/logoutから始めて、おそらく私は本当にGET何もしないので-POSTへのリクエストが/logoutに適切で、セッションを破棄してからGETリダイレクト。 /logoutの用語はそのままにしておく必要がありますか？

/loginと/registerはどうですか。 /registerを/registrationに変更することはできますが、それにより私のサービスが根本的に機能する方法は変わりません-より深い問題がある場合。

/userリソースを公開することはありません。おそらくそれはどういうわけか利用できるでしょう。たとえば、ユーザーmyUserを使用します。

foo.com/user/myUser

または

foo.com/user

エンドユーザーは、URIに余分な冗長性を必要としません。ただし、視覚的により魅力的なのはどれですか？

このSOビジネスに関するRESTで他の質問にここで気づきましたが、可能であれば、ここで何をレイアウトしたかについてのガイダンスを本当に感謝します。

ありがとう！

更新：

私もいくつかの意見が欲しい：

/user/1

対

/user/myUserName
web-servicesapiresthttprestful-url
105
Qcom

特に、RESTに対応していないということは、ログアウトにGETリクエストを使用することです。

（ http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods から）

一部のメソッド（たとえば、HEAD、GET、OPTIONS、TRACE）は安全であると定義されています。つまり、情報の取得のみを目的としており、サーバーの状態を変更しないでください。言い換えれば、ロギング、キャッシュ、バナー広告の配信、Webカウンターの増分などの比較的無害な効果を超えて、副作用が発生してはなりません。 [...]

[... H]サーバーによる[GETリクエストの]アンドリングは、技術的に制限されていません。したがって、不注意または意図的なプログラミングは、サーバー上で重要な変更を引き起こす可能性があります。これは、Webキャッシング、検索エンジン、その他の自動エージェントに問題を引き起こす可能性があるため、推奨されません[...]

ログアウトとリダイレクトに関しては、ログアウトURIへの投稿に、ログアウト後のページにリダイレクトする303応答を与えることができます。

http://en.wikipedia.org/wiki/Post/Redirect/Get

http://en.wikipedia.org/wiki/HTTP_3

編集してURL設計の問題に対処します。

「リソースをどのように設計しますか？」私にとって重要な質問です。 「URLをどのように設計しますか？」次の2つの領域の考慮事項です。

ユーザーに表示されるURLは、できればtooくて意味のあるものであってはなりません。あるリソースへのリクエストでCookieを送信し、他のリソースへは送信しないようにするには、パスとCookieパスを構造化します。

JRandomUserが自分のプロファイルを確認したい場合で、URLをfoo.com/user/JRandomUserまたはfoo.com/user/(JRandom's numeric user id here)よりもきれいにしたい場合、ユーザーが自分の情報を見るためだけに別のURLを作成できます。 ：

GET foo.com/profile /*examines cookies to figure out who 
                     * is logged in (SomeUser) and then 
                     * displays the same response as a
                     * GET to foo.com/users/SomeUser.
                     */

私はこの主題についての知恵よりもはるかに容易に無知を主張しますが、ここにいくつかのリソース設計の考慮事項があります。

  1. コンシューマー：どのリソースがブラウザーで直接表示されるか、XHRを介してロードされるか、または他の種類のクライアントによってアクセスされることを意図していますか？
  2. アクセス/ ID：応答はCookieまたはリファラーに依存しますか？
56
ellisbben

RESTfulは、URLを構築するためのガイドラインとして使用でき、sessionsおよびsersリソースを作成できます。

  • GET /session/newは、ログインフォームがあるWebページを取得します
  • POST /sessionはデータベースに対して資格情報を認証します
  • DELETE /sessionはセッションを破棄し、/にリダイレクトします
  • GET /users/newは、登録フォームがあるWebページを取得します
  • POST /usersは、入力された情報を新しい/ user/xxxとしてデータベースに記録します
  • GET /users/xxx //プロファイルビューで現在のユーザーデータを取得してレンダリングします
  • POST /users/xxx //ユーザーに関する新しい情報を更新します

これらは複数形でも単数形でも構いません（どちらが正しいかはわかりません）。通常、ユーザーインデックスページに/usersを使用し（予想どおり）、/sessionsを使用して、ログインしているユーザーを表示します（予想どおり）。

URLで番号の代わりに名前（/users/43と/users/joe）を使用することは、通常、技術的な要件ではなく、ユーザーや検索エンジンにより親しみを持たせたいという願望に基づいています。どちらでも構いませんが、一貫性を保つことをお勧めします。

Register/login/logoutまたはsign(in|up|out)を使用すると、安らかな用語ではうまく機能しないと思います。

107
ndp

セッションはRESTfulではありません

  • はい、知っています。通常はOAuthを使用して行われていますが、実際にはセッションはRESTfulではありません。主にセッションが必要ないため、/ login/logoutリソースを使用しないでください。

  • 実行する場合は、RESTfulにします。リソースは名詞であり、/ loginと/ logoutは名詞ではありません。/sessionを使用します。これにより、作成と削除がより自然なアクションになります。

  • セッションのPOSTとGETは簡単です。ユーザー/パスワードを変数として送信している場合、POSTを使用します。URIの一部としてパスワードを送信したくないためです。ログに表示され、場合によってはワイヤ上で公開されます。また、GET argsの制限でソフトウェアが失敗するリスクもあります。

  • 通常、RESTサービスでは基本認証を使用するか、認証を使用しません。

ユーザーの作成

  • これは1つのリソースであるため、/ registerは必要ありません。

    • POST/user-リクエスターがIDを指定できない場合にユーザーを作成します
    • PUT/user/xxx-事前にIDを知っていると仮定してユーザーを作成または更新します
    • GET/user-x個のユーザーIDをリストします
    • GET/user/xxx-ID xxxのユーザーの詳細を取得します
    • DELETE/user/xxx-ID xxxのユーザーを削除します

  • どの種類のIDを使用するかは難しい質問です。一意性を強制すること、削除された古いIDの再利用について考える必要があります。たとえば、IDがリサイクルされる場合（可能な場合）、それらのIDをバックエンドの外部キーとして使用することは望ましくありません。ただし、外部/内部ID変換のルックアップを使用して、バックエンドの要件を緩和できます。

51
dietbuddha

さまざまなREST Webサービスをモバイルアプリに使用するか、サーバー間通信に使用するかを問わず、さまざまなREST AP​​Iを統合した経験から話をします。その他。以下は、他の人のREST AP​​Iから収集した観察結果と、私たちが自分で作成した観察結果です。

  • APIといえば、通常はプログラミングインターフェースのセットを指し、プレゼンテーション層は必要ありません。 RESTもデータ中心であり、プレゼンテーション駆動型ではありません。つまり、ほとんどのRESTはJSONまたはXMLの形式でデータを返し、特定のプレゼンテーションレイヤーを返すことはめったにありません。マルチチャネル配信を行うREST能力が与えられた（直接的なWebページではなくデータを返す）この特性。同じWebサービスをHTML、iOS、Androidでレンダリングできること、またはサーバー間の組み合わせとして使用できることを意味します。
  • HTMLとRESTの両方をURLとして組み合わせることは非常にまれです。デフォルトでは、RESTはサービスと見なされ、プレゼンテーション層はありません。 Webサービスを使用するユーザーは、必要なものに応じて呼び出すサービスからデータをレンダリングするのが仕事です。それまでのURLは、これまでに出会ったほとんどのRESTベースのデザイン（またはFacebookやTwitterから来ている人などの標準）に準拠していません
 GET/register //登録フォームがあるWebページを取得します
  • 前のポイントから続けて、RESTベースのサービスが以下に示すようなリダイレクトを行うことも珍しいです（そして私は遭遇していません）。
 GET/logout //セッションを破棄し、/ 
 POST/loginにリダイレクトします//データベースに対して認証情報を認証し、新しいセッションでホームをリダイレクトするか、/ login 
にリダイレクトします。 

RESTはサービスとして設計されているため、ログインやログアウトなどの機能は通常、成功/失敗結果（通常はJSONまたはXMLデータ形式）を返し、消費者はそれを解釈します。そのような解釈には、あなたが言ったように適切なウェブページへのリダイレクトが含まれる可能性があります

  • RESTでは、URLは実行されるアクションを示します。そのため、できるだけあいまいさを排除する必要があります。異なるアクションを実行する同じパス（/ registerなど）を持つGETとPOSTの両方を持つことが正当な場合ですが、そのような設計は提供されるサービスにあいまいさをもたらし、サービスの消費者を混乱させる可能性があります。たとえば、以下で紹介するようなURLは、RESTベースのサービスには理想的ではありません
 GET/register //登録フォームのあるWebページを取得します
 POST/register //入力した情報を新しい/user/xxx
としてデータベースに記録します

これらは私が対処したことからのいくつかのポイントです。あなたにいくつかの洞察を提供してくれることを願っています。

これで、RESTの実装に関する限り、これらは私が遭遇した典型的な実装です。

  •  GET/logout

    バックエンドでログアウトを実行し、操作の成功/失敗を示すJSONを返します

  •  POST /login

    バックエンドに資格情報を送信します。成功/失敗を返します。成功した場合、通常はセッショントークンとプロファイル情報も返します。

  •  POST /register

    バックエンドに登録を送信します。成功/失敗を返します。成功した場合、通常は成功したログインと同様に扱われます。または、別個のサービスとして登録することを選択できます。

  •  GET /user/xxx

    ユーザープロファイルを取得し、ユーザーのプロファイルのJSONデータ形式を返す

  •  POST/user/xxx 
 //は
 POST /updateUser/xxx
に名前が変更されました

    更新されたプロファイル情報をJSON形式として投稿し、バックエンドの情報を更新します。呼び出し元に成功/失敗を返す

20
momo

これは認証に対するRESTfulなアプローチだと思います。ログインには、HttpPutを使用します。このHTTPメソッドは、キーが提供され、繰り返し呼び出しがcan等である場合に作成に使用できます。 LogOffの場合、HttpDeleteメソッドで同じパスを指定します。動詞は使用されません。適切なコレクションの複数形。 HTTPメソッドは目的をサポートします。

[HttpPut]
[Route("sessions/current")]
public IActionResult LogIn(LogInModel model) { ... }

[HttpDelete]
[Route("sessions/current")]
public IActionResult LogOff() { ... }

必要に応じて、アクティブをアクティブに置き換えることができます。

3
Chad Kuehn

Twitterに似たユーザーアカウントURLを使用することをお勧めします。ユーザーのアカウントURLは、URL https：//で自分のTwitterアカウントにアクセスできるように、foo.com/myUserNameのようになります。 Twitter.com/joelbyler

POSTが必要なログアウトについては同意しません。 APIの一部として、セッションを維持する場合、UUIDの形式のセッションIDは、ユーザーを追跡し、実行されているアクションが許可されていることを確認するために使用できるものです。その後、GETでさえセッションIDをリソースに渡すことができます。

簡単に言えば、URLはシンプルで覚えやすいものにすることをお勧めします。

2
joelbyler