タグ付けされた質問 「rest」

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 REST APIからエラーが返されるようになると、良い習慣に関するガイダンスを探しています。私は新しいAPIに取り組んでいるので、今はどの方向にでも進むことができます。現在のコンテンツタイプはXMLですが、将来はJSONをサポートする予定です。 たとえば、クライアントが新しいリソースを追加しようとしたが、ストレージクォータを超えたなど、いくつかのエラーケースを追加しています。HTTPステータスコード（認証は401、承認は403、プレーンなリクエストURIは404）を使用して、特定のエラーケースをすでに処理しています。祝福されたHTTPエラーコードを調べましたが、アプリケーション固有のエラーを報告するのに適切な範囲である400〜417の範囲はありません。したがって、最初は200 OKと特定のXMLペイロードでアプリケーションエラーを返したくなりました（つまり、さらに料金を払えば、必要なストレージを取得できます）。ホラーに肩をすくめる）。その上、エラーレスポンスを別個のケースに分割しているような気がします。いくつかはhttpステータスコードドリブンで、他はコンテンツドリブンです。 では、業界の推奨事項は何ですか？グッドプラクティス（理由を説明してください！）と、クライアントの視点から、REST APIでどのようなエラー処理を行うと、クライアントコードの処理が容易になりますか？

623 web-services  http  rest 

PHPベースのWebアプリケーション、データベース、CMSのデフォルト関数をAPIでラップする方法を探しています。 私は周りを見回して、いくつかの「スケルトン」フレームワークを見つけました。私の質問の回答に加えて、非常に軽量であることから気に入っているRESTフレームワークであるTonicがあります。 RESTはそのシンプルさから最も気に入っており、それに基づいてAPIアーキテクチャを作成したいと考えています。私は基本原則を理解しようとしていますが、まだ完全には理解していません。したがって、いくつかの質問。 1.私はそれを正しく理解していますか？ 「ユーザー」というリソースがあるとします。私は次のようにいくつかのURIを設定できます： /api/users when called with GET, lists users /api/users when called with POST, creates user record /api/users/1 when called with GET, shows user record when called with PUT, updates user record when called with DELETE, deletes user record これは、これまでのところRESTfulアーキテクチャの正しい表現ですか？ 2.動詞がもっと必要 理論的には作成、更新、削除で十分かもしれませんが、実際にはもっと多くの動詞が必要になります。これらは更新リクエストに埋め込むことができるものであることに気づきましたが、これらは特定の戻りコードを持つ特定のアクションであり、それらすべてを1つのアクションに投げたくありません。 ユーザーの例で頭に浮かぶのは次のとおりです。 activate_login deactivate_login change_password add_credit …

602 web-services  rest 

RESTシステムとRESTfulなシステムの違いは何ですか？ 私が最もよく読んだいくつかのことから、いわゆるRESTサービスは実際にはRESTfulなサービスです。では、2つの違いは何ですか。

540 architecture  rest 

いくつかの説明が必要です。私はRESTについて読んでいて、RESTfulアプリケーションを構築しています。ウィキペディアによれば、REST自体は、Representational State Transferとして定義されています。したがって、私は誰もが吐き続けているこの無国籍のゴブレイディーグックをすべて理解していません。 ウィキペディアから： 特定の時点で、クライアントはアプリケーションの状態間または「休止中」に移行できます。休止状態のクライアントは、ユーザーと対話できますが、サーバーのセットまたはネットワーク上で負荷を発生させず、クライアントごとのストレージを消費しません。 彼らは単にセッション/アプリケーションレベルのデータストアを使用しないと言っていますか??? RESTの1つの目標は、たとえば、ページング要求を投稿内に隠して、要求のページ番号をGET URIの一部にするのではなく、URIアクセスを一貫して利用可能にすることです。私には理にかなっています。しかし、クライアントごとのデータ（セッションデータ）をサーバー側に保存するべきではないと言っているだけのようです。 メッセージのキューがあり、ユーザーがメッセージを読みたいが、メッセージを読んでいるときに、セッション中に特定の送信者のメッセージがブロックされるようにしたい場合はどうなりますか？これをサーバー側の場所に保存し、ユーザーがブロックしていないメッセージ（またはメッセージID）のみをサーバーに送信させるのは意味がないのでしょうか。 新しいメッセージリストを要求するたびにブロックするために、メッセージ送信者のリスト全体を送信する必要がありますか？私に関係のあるメッセージリストは、そもそも公に利用できるリソースではないはずです。 繰り返しますが、これを理解しようとしています。誰かが明確にしてください。 更新： スタックオーバーフローの質問が見つかりましたが、そこまでは行きませんでした。 重要なクライアントの状態はすべてのリクエストで転送する必要があるというRESTでの状態の管理方法 ... Ugg ..オーバーヘッドが多いようです...これでよろしいですか？

536 rest  session-state 

RESTは初めてですが、一部のRESTfulサービスでは、更新/取得/削除と作成に異なるリソースURIを使用していることがわかりました。といった 作成-使用/リソースを使用していくつかの場所で、POSTメソッド（複数の観察）で/リソースを（単数形） 更新-PUTメソッドで/ resource / 123を使用 Get- GETメソッドで/ resource / 123を使用する このURIの命名規則について少し混乱しています。リソースの作成には、複数形または単数形を何を使用すればよいですか？それを決定する際の基準は何ですか？

529 rest  resources  naming-conventions  uri 

これは違いに関する一般的な質問の詳細ですtext/xmlとapplication/xml。私はWebサービス（REST-ジャージー）を書くのはかなり新しいです。私がapplication/xml学習に使用しているほとんどのチュートリアル/コード例に表示されるものなので、私は制作してきましたがtext/xml、最近、何が違うのか、いつ使用するのかについて知り、疑問に思っていましたapplication/xml。

495 xml  rest  jersey 

RESTful APIでのセッションの使用は本当にRESTfulnessに違反していますか？私は多くの意見がどちらの方向にも進んでいるのを見てきましたが、セッションがRESTなしであるとは思いません。私の視点から： 認証はRESTfulnessで禁止されていません（そうでなければRESTfulサービスではほとんど使用されません） 認証は、リクエストで認証トークンを送信することで行われ、通常はヘッダー この認証トークンは何らかの方法で取得する必要があり、取り消すことができます。その場合、更新する必要があります 認証トークンはサーバーによって検証される必要があります（そうでなければ、認証ではありません） では、セッションはこれにどのように違反しますか？ クライアント側、セッションはcookieを使用して実現されます Cookieは単なる追加のHTTPヘッダーです セッションCookieはいつでも取得して取り消すことができます セッションCookieは、必要に応じて無限の寿命を持つことができます セッションID（認証トークン）はサーバー側で検証されます そのため、クライアントにとって、セッションCookieは、他の独自のヘッダーのCookie代わりにヘッダーを使用することを除いて、他のHTTPヘッダーベースの認証メカニズムとまったく同じAuthorizationです。サーバー側のCookie値にセッションがアタッチされていない場合、なぜ違いが生じるのでしょうか？サーバーが RESTfulに動作する限り、サーバー側の実装はクライアントに関係する必要はありません。そのため、Cookie自体はAPIをRESTlessにすべきではなく、セッションは単にクライアントへのCookieです。 私の仮定は間違っていますか？セッションCookieをRESTレスにするものは何ですか？

491 session  rest  cookies  restful-authentication 

REST APIに使用しているHttpClientがあります。しかし、Authorizationヘッダーの設定に問題があります。ヘッダーを、OAuthリクエストの実行から受け取ったトークンに設定する必要があります。私は以下を示唆する.NET用のコードを見ました、 httpClient.DefaultRequestHeaders.Authorization = new Credential(OAuth.token); ただし、CredentialクラスはWinRTには存在しません。誰でもAuthorizationヘッダーを設定する方法について何かアイデアがありますか？

483 c#  rest  oauth  windows-runtime 

イントラネットアプリ用にHTTPベースのAPIを設計しています。私はそれが物事の大まかな体系ではかなり小さな懸念事項であることを理解していますが、URI内の単語を区切るためにハイフン、アンダースコア、またはキャメルケースを使用する必要がありますか？ これが私の最初の考えです。 キャメルケース サーバーで大文字と小文字が区別されない場合に考えられる問題 クエリ文字列のキーにかなり広範囲に使用しているようだ（http://api.example.com？SEARCHQUERY = ...）ではなく、他のURIの部分で ハイフン 他の選択肢よりも審美的に楽しい URIのパス部分で広く使用されているようです 実際にハイフネーションされたクエリ文字列キーを見たことがない おそらく SEOに適しています（これは神話かもしれません） 下線 プログラミング言語が扱いやすい可能性 いくつかの人気のあるAPI（Facebook、Netflix、StackExchangeなど）は、URIのすべての部分でアンダースコアを使用しています。 私はすべてのアンダースコアに傾いています。大企業のほとんどがそれらを使用しているという事実は説得力があります（https://stackoverflow.com/a/608458/360570を参照）。

477 api  url  rest  uri  restful-url 

ジャージーでトークンベースの認証を有効にする方法を探しています。特定のフレームワークを使用しないようにしています。それは可能ですか？ 私の計画は、ユーザーがWebサービスにサインアップし、Webサービスがトークンを生成してクライアントに送信し、クライアントがそれを保持することです。次に、クライアントは、要求ごとに、ユーザー名とパスワードの代わりにトークンを送信します。 リクエストごとにカスタムフィルターを使用する@PreAuthorize("hasRole('ROLE')") ことを考えていましたが、これにより、データベースへの多くのリクエストにより、トークンが有効であるかどうかが確認されると思いました。 または、フィルターを作成せず、各リクエストにparamトークンを入れますか？そのため、各APIはまずトークンをチェックし、その後、リソースを取得するために何かを実行します。

459 java  rest  authentication  jax-rs  jersey-2.0 

チュートリアルで説明されているように、URLでパラメーターをキャプチャするために、現在正規表現を定義しています。HttpRequestオブジェクトの一部としてURLからパラメーターにアクセスするにはどうすればよいですか？私はHttpRequest.GET現在、空のQueryDictオブジェクトを返します。 ライブラリなしでこれを行う方法を学びたいので、Djangoについて詳しく知ることができます。

458 django  url  rest 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 現在、PHPでRESTful APIを設計および実装しています。しかし、私は最初の設計の実装に失敗しています。 GET /users # list of users GET /user/1 # get user with id 1 POST /user # create new user PUT /user/1 # modify user with id 1 DELETE /user/1 # delete user with id 1 これまでのところ、かなり標準的ですよね？ 私の問題は最初のものGET /usersです。リストをフィルタリングするために、リクエスト本文でパラメーターを送信することを検討していました。これは、次のように、非常に長いURLを取得せずに複雑なフィルターを指定できるようにするためです。 GET /users?parameter1=value1&parameter2=value2&parameter3=value3&parameter4=value4 代わりに、私は次のようなものを望んでいました： GET /users # …

457 api  search  rest  filter 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 私はHTTPを経由するようにAPIを設計していて、HTTP POSTコマンドを使用するのかどうか疑問に思っていますが、URLクエリパラメータのみを使用し、リクエストボディを使用しないのが良い方法です。 考慮事項： 「優れたWebデザイン」では、POSTを介してべき等でないアクションを送信する必要があります。これはべき等ではないアクションです。 リクエストパラメータがURLに含まれていると、このアプリの開発とデバッグが簡単になります。 APIは、広範囲での使用を目的としていません。 本文なしでPOSTリクエストを行うと、少し作業が増えるようです。たとえば、Content-Length: 0ヘッダーを明示的に追加する必要があります。 また、ボディのないPOSTは、ほとんどの開発者やHTTPフレームワークの期待に少し反しているようにも思えます。 リクエストの本文ではなく、URLクエリを介してPOSTリクエストでパラメーターを送信することに他に落とし穴や利点はありますか？ 編集：これが検討されている理由は、操作がべき等ではなく、取得以外の副作用があるためです。HTTP仕様を参照してください。 特に、GETメソッドとHEADメソッドは、取得以外のアクションを実行することの重要性を持たないことが規約に定められています。これらの方法は「安全」であると考えられるべきです。これにより、ユーザーエージェントはPOST、PUT、DELETEなどの他のメソッドを特別な方法で表すことができ、ユーザーは安全でない可能性のあるアクションが要求されているという事実を知ることができます。 ... メソッドは、「偶数性」のプロパティを持つこともできます（エラーまたは期限切れの問題は別として）N> 0の同一リクエストの副作用は単一リクエストの場合と同じです。メソッドGET、HEAD、PUT、DELETEはこのプロパティを共有します。また、メソッドOPTIONSおよびTRACEには副作用がないため、本質的にべき等です。

451 rest  http 

PUTレスポンスボディで何も返さない（null）RESTfulな操作についての人々の意見は何だろうと思っていました。

437 resources  rest  service  put 

この質問は、GETまたはPOSTを一般的にいつ使用するかに関するものではありません。これは、Webアプリケーションのログアウトを処理するために推奨される方法です。一般的な意味でのGETとPOSTの違いに関する多くの情報を見つけましたが、この特定のシナリオに対する明確な答えは見つかりませんでした。 実用主義者として、私はGETを使用する傾向があります。GETの実装はPOSTよりもはるかに簡単だからです。単純なリンクをドロップするだけで完了です。これは、少なくとも頭のてっぺんから、私が考えることができる大多数のWebサイトに当てはまるようです。Stack Overflowでも、GETを使用してログアウトを処理します。 私が躊躇しているのは、一部のWebアクセラレータ/プロキシがページ内で見つかったすべてのリンクに移動して取得することでページをプリキャッシュする（古い）引数であり、ユーザーがクリックしたときにユーザーがより迅速に応答するようにします。これがまだ当てはまるかどうかはわかりませんが、これが当てはまる場合、理論的には、これらのアクセラレータのいずれかを使用しているユーザーは、ログインするとすぐにアプリケーションから追い出されます。彼女はそれをクリックしなかった場合でも、リンク。 これまでに読んだことはすべて、POSTは「破壊的なアクション」に使用する必要があることを示唆していますが、アプリケーションの内部状態を変更しないアクション（クエリなど）はGETで処理する必要があります。これに基づいて、ここでの本当の質問は次のとおりです。 アプリケーションからのログアウトは破壊的なアクションと見なされますか/それはアプリケーションの内部状態を変更しますか？

433 architecture  rest  post  get