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

HTTPリダイレクトは、HTTPコード301および302（他のコードも可能）と、新しい場所の住所を持つ「ロケーション」として知られるヘッダーフィールドを介して行われます。ただし、ブラウザは常にそのURLに「GET」リクエストを送信します。 ただし、多くの場合、POSTを介してユーザーを別のドメインにリダイレクトする必要があります（銀行支払いなど）。これは一般的なシナリオであり、実際には要件です。HTTP仕様でこのような一般的な要件が無視されている理由を知っている人はいますか？回避策は、アクションをターゲットの場所（Locationヘッダーフィールドの値）に設定したフォーム（非表示フィールドのパラメーター付き）setTimeoutを送信し、それを使用してフォームをターゲットの場所に送信することです。

162 web-development  web-applications  http 

インターネット全体で、次のアドバイスが表示されます。 GETはサーバー上のデータを変更してはいけません-そのためにPOSTリクエストを使用してください この考えの根拠は何ですか？ データベースにデータを挿入するphpサービスを作成し、GETクエリ文字列でパラメーターを渡すと、なぜ間違っているのですか？（SQLインジェクションを処理するために、準備済みステートメントを使用しています）。POSTリクエストは何らかの方法でより安全ですか？ または、これには何らかの歴史的な理由がありますか？もしそうなら、このアドバイスは今日どのくらい有効ですか？

109 http  http-request 

ユーザーがサーバーに1つのHTTPリクエストで複数のアクションを実行するように要求できるAPIを構築しています。結果は、アクションごとに1つのエントリを持つJSON配列として返されます。 これらの各アクションは、互いに独立して失敗または成功する場合があります。たとえば、最初のアクションが成功し、2番目のアクションへの入力のフォーマットが不適切で検証に失敗し、3番目のアクションが予期しないエラーを引き起こす場合があります。 アクションごとに1つのリクエストがある場合、ステータスコード200、422、および500をそれぞれ返します。しかし、リクエストが1つしかない場合、どのステータスコードを返す必要がありますか？ いくつかのオプション： 常に200を返し、より詳細な情報を本文に記載します。 リクエストに複数のアクションがある場合にのみ上記のルールに従うのでしょうか？ すべてのリクエストが成功した場合は200を返し、そうでない場合は500（または他のコード）を返しますか？ アクションごとに1つの要求を使用し、余分なオーバーヘッドを受け入れます。 まったく違うものですか？

72 api  http 

最近、アプリケーション状態のエンジン（HATEOAS）としてのハイパーメディアについて読んでいます。これは、Web APIを「真にRESTful」とする制約です。基本的に、現在の状態から可能な遷移へのすべての応答にリンクを含めることになります。 HATEOASが私の理解に基づいていることを説明させてください。何かを見逃した場合は、訂正してください。 / GET: { "_links": { "child": [ { "href": "http://myapi.com/articles", "title": "articles" } ] } } /articles?contains=HATEOAS GET: { "_items": [ { "uri": "http://myapi.com/articles/0", "title": "Why Should I Care About HATEOAS?" }, { "uri": "http://myapi.com/articles/1", "title": "HATEOAS: Problem or Solution?" } ], "_links": { "self": { "href": …

61 rest  http  hateoas 

私はRESTful APIの末尾のスラッシュをどうするかについて議論していました。 犬と呼ばれるリソースと、個々の犬用の下位リソースがあるとします。したがって、次のことができます。 GET/PUT/POST/DELETE http://example.com/dogs GET/PUT/POST/DELETE http://example.com/dogs/{id} しかし、次の特別な場合はどうしますか： GET/PUT/POST/DELETE http://example.com/dogs/ 私の個人的な見解では、これはid =で個々のdogリソースにリクエストを送信するということnullです。この場合、APIは404を返すはずです。 他の人は、リクエストがdogsリソースにアクセスしている、つまり末尾のスラッシュが無視されると言います。 誰もが決定的な答えを知っていますか？

60 api  rest  http 

私はプロジェクトに取り組んでおり、職場の人々と約1時間以上議論した後です。スタック交換の人々が何を言うかを知ることにしました。 システム用のAPIを作成しています。組織のツリーまたは目標のツリーを返すクエリがあります。 組織のツリーは、ユーザーが存在する組織です。つまり、このツリーは常に存在する必要があります。組織では、目標ツリーが常に存在する必要があります。（それが引数の始まりです）。ツリーが存在しない場合、同僚はステータスコード200で応答するのが正しいと判断しました。その後、ツリーがないときにアプリケーションがバラバラになるため、コードを修正するように頼み始めました。 私は炎と怒りをspareしまないようにします。 ツリーがない場合、404エラーを発生させることを提案しました。少なくとも何かが間違っていることを知らせてくれるでしょう。200を使用する場合、エラーを処理するために成功コールバックの応答に特別なチェックを追加する必要があります。オブジェクトを受け取ることを期待していますが、何も見つからないため、実際には空の応答を受け取る場合があります。応答を404としてマークするのはまったく公平に思えます。その後、戦争が始まり、HTTPステータスコードスキーマを理解していないというメッセージを受け取りました。だから私はここにいて、この場合の404の何が問題なのか尋ねていますか？「何も見つからなかったので、200を返すのは正しい」という議論もありました。ツリーは常に存在する必要があるため、これは間違っていると思います。何も見つからず、何かを期待している場合は、404になります。 詳細、 取得したURLを追加するのを忘れました。 組織 /OrgTree/Get 目標 /GoalTree/GetByDate?versionDate=... /GoalTree/GetById?versionId=... 私の間違い、両方のパラメーターが必要です。日付に解析できるversionDateが提供されている場合、終了リビジョンを返します。過去に何かを入力すると、最初のリビジョンが返されます。IDが存在しないIDである場合、200の空の応答を返すと思われます。 追加 また、この問題に対する最善の答えは、組織の作成時にデフォルトのオブジェクトを作成することであり、ツリーを持たないことは有効なケースではなく、未定義の動作と見なすべきです。両方のツリーがなければアカウントを使用する方法はありません。そのため、それらは常に存在する必要があります。 また、私はこれをリンクしました（1つは似ていますが、見つけることができません） http://viswaug.files.wordpress.com/2008/11/http-headers-status1.png

58 api  http  http-response 

パラメーターとして整数を使用するRESTエンドポイントがあるとします。 /makeWaffles?numberOfWaffles=3 この場合、負の数のワッフルを作ることができないため、この数を正にしたいです（そして、0のワッフルを要求するのは時間の無駄です）。したがって、正の整数を含まない要求を拒否したいと思います。また、最大の整数を超えるリクエストを拒否したい（今はMAX_INTEGERであるとしましょう）。 誰かが非正数のワッフルをリクエストした場合、HTTP 400（Bad Request）ステータスを返すべきですか？私の最初の考えはイエスです：それは私がリクエストを完了するための有効な数字ではありません。ただし、RFCでは、ビジネスルールをスローする理由として言及していません。 400（Bad Request）ステータスコードは、クライアントエラー（たとえば、不正な要求構文、無効な要求メッセージのフレーミング、または不正な要求ルーティング）が原因でサーバーが要求を処理できないか、処理しないことを示します。 ビジネスルールは、これら3つの例のいずれにも該当しません。これは構文的に正しく、適切にフレーム化されており、不正なリクエストルーティングではありません。 パラメータが構文的に正しいが、ビジネスルールに違反している場合、HTTP 400（Bad Request）ステータスを返す必要がありますか？または、返すのに適切なステータスがありますか？

56 api-design  http 

私が扱ったいくつかのサーバーは、クライアントが失敗と見なすべきリクエストに対してHTTP 200を返します。本文には「success：false」のようなものが含まれます。 これは、特に認証に失敗した場合、HTTPコードの適切な実装とは思えません。「4xx」は変更するまでリクエストを再度行うべきではないことを示し、「5xx」はリクエストが有効または無効であり、再試行できるが失敗したことを示すため、HTTPエラーコードを簡潔に要約しました。この場合、200：ログインに失敗した、または200：そのファイルが見つからなかった、または200：パラメータxが見つからない、間違いが間違っているようです。 一方、「4xx」はリクエストの構造的な問題を示すだけであるという議論が行われていることがわかりました。したがって、200を返すのは適切です。401不正ではなく、不正なユーザー/パスワードは、クライアントが要求を行うことを許可されているためです。この引数は、サーバーが要求を処理して決定を行うことができた場合、応答コードは200である必要があり、詳細については本文を確認するのはクライアント次第であると要約できます。 基本的に、これは好みの問題のようです。しかし、それは満足のいくものではないので、これらのパラダイムのいずれかがより正しい理由が誰かにあるなら、私は知りたいです。

54 http  server  error-handling  client-server 

現在、5つの都市でサービスを提供しています。誰かが他の都市からサービスAPIを呼び出そうとした場合、このエラーをスローしますService not available in your area。 問題は、このエラーに適切なhttpコードは何ですか？ 503：サービスを利用できません 403禁止します または、他の何か？

51 api  api-design  http 

私はモバイルクライアント用の一連のWebサービスに取り組んでいます。要件では、すべてのリクエストに含まれ、特定のリクエストに格納され、他のリクエストで結果をフィルタリングするために使用される一意のデバイスIDが必要です。 すべてのリクエストに含まれるので、カスタムHTTPヘッダーに入れることを提案しました。そのため、特定のデータがヘッダーにあるのか、他のデータと一緒にあるのかを判断するためにどの基準を使用するのか疑問に思い始めましたリクエスト本文。 そのような基準はありますか？

51 http  http-request 

私はこれについて疑問に思っていました。 フィールドとフィールドを持つuserリソースがあるidとしnameます。フィールドを更新したい場合は、次のようにリソースに対してPATCHリクエストを行うことができます。 PATCH /users/42 {"name": "john doe"} そして、アプリケーションはユーザー42の名前を更新します。 しかし、なぜこのリクエストを繰り返した場合、結果が異なるのでしょうか？ よると、RFC 5789 PATCHは安全でもi等でもありません

48 rest  api-design  http  web-api 

最終的な処理のために長時間実行されるタスクをキューに入れることをサポートするRESTful APIを構築しています。 このAPIの一般的なワークフローは次のとおりです。 ユーザーがフォームに入力する クライアントがデータをAPIに投稿します APIは202 Acceptedを返します クライアントはユーザーをそのリクエストの一意のURLにリダイレクトします（/results/{request_id}） 〜最終的に〜 クライアントは再度URLにアクセスし、そのページで結果を確認します。 問題はステップ6にあります。ユーザーがページにアクセスするたびに、API（GET /api/results/{request_id}）にリクエストを提出します。理想的には、タスクは今までに完了しており、タスクの結果と共に200 OKを返します。 しかし、ユーザーは強引であり、結果がまだ処理を完了していないときに、多くの熱心な更新が期待されます。 次のことを示すステータスコードの最良の選択肢は何ですか？ このリクエストが存在する、 まだ終わっていない、 しかし、それも失敗していません。 単一のコードがすべてを通信することを期待していませんが、クライアントにコンテンツを期待させるのではなく、メタデータを渡すことができるものが欲しいのです。 202を返すことは理にかなっています。なぜなら、それはここでは他の意味を持たないからです。それはGET要求であるため、おそらく「受け入れられる」ものは何もありません。それは合理的な選択でしょうか？ これらすべてに対する明白な代替手段-機能するが、ステータスコードの1つの目的を無効にする-は、常にメタデータを含めることです。 200 OK { status: "complete", data: { foo: "123" } } ...または... 200 OK { status: "pending" } 次に、クライアント側で、リクエストが完了したかどうかを判断するためswitchに（ため息をつきます）response.data.status。 これは私がやるべきことですか？または、より良い代替手段はありますか？これは私にとってWeb 1.0だと感じています。

47 rest  http 

HTTP GETリクエストに応答して、REST API がサブオブジェクトで追加データを返すと仮定しますowner。 { id: 'xyz', ... some other data ... owner: { name: 'Jo Bloggs', role: 'Programmer' } } 明らかに、誰もがPUTバックアップできるようにしたくない { id: 'xyz', ... some other data ... owner: { name: 'Jo Bloggs', role: 'CEO' } } そしてそれを成功させます。確かに、この場合、おそらく潜在的に成功する方法さえ実装しないでしょう。 しかし、この質問はサブオブジェクトだけではありません。一般的に、PUTリクエストで変更できないデータを使用して何を行う必要がありますか？ PUTリクエストから欠落している必要がありますか？ 静かに捨てるべきですか？ チェックする必要があり、その属性の古い値と異なる場合、応答でHTTPエラーコードを返しますか？ または、JSON全体を送信するのではなく、RFC 6902 JSONパッチを使用する必要がありますか？

46 rest  http  http-request 

RESTサービスの仕様をまとめています。RESTサービスの一部には、サービス全体およびリソースのグループまたは個々のリソースでユーザーを調整する機能が組み込まれています。同様に、これらのタイムアウトは、リソース/グループ/サービスごとに構成できます。 HTTP 1.1仕様を調べて、クライアントが制限に達したために要求が満たされないことをクライアントに伝える方法を決定しようとしています。 最初は、クライアントコード403 - Forbiddenが1つであると考えましたが、これは仕様からです。 承認は役に立たず、リクエストは繰り返されるべきではありません 私を悩ませた。 実際に503 - Service Unavailableは、使用するほうが良いようです- Retry-Afterヘッダーを使用することで再試行時間の通信が可能になるためです。 将来的には、eコマースを介してより多くのリクエストを「購入」することをサポートする可能性があります（この場合、クライアントコード402 - Payment Requiredが確定されていればいいと思います！）。 私はどちらを使うべきだと思いますか？または、私が考慮していない別のものがありますか？

43 web-services  rest  http 

RESTful APIの設計を進めています。特定のリソースに対してJSONとXMLを返したいことがわかっています。私はこのようなことをすると思っていました。 GET /api/something?param1=value1 Accept: application/xml (or application/json) ただし、次のように、誰かがこのために拡張機能を使用して投げ出しました： GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1) これらのアプローチのトレードオフは何ですか？拡張機能が指定されていない場合はacceptヘッダーに依存するのが最善ですが、指定されている場合は拡張機能を優先しますか？そのアプローチには欠点がありますか？

40 architecture  web-services  rest  http