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

HTTPステータスコードは、HTTP Web応答で返される標準化されたコードのセットです。サービスが（予期せず）ステータスコードを返す理由に関する質問では、このタグを使用しないでください。

17
403 Forbidden vs 401 Unauthorized HTTPレスポンス
存在するが、ユーザーに十分な権限がない（ログインしていない、または適切なユーザーグループに属していない）Webページの場合、適切なHTTP応答は何ですか？ 401 Unauthorized？ 403 Forbidden？ 他に何か？ これまでにそれぞれについて読んだことは、2つの違いについてはあまり明確ではありません。各応答に適切なユースケースは何ですか？
15
リソースがすでに存在する場合のPOSTのHTTP応答コード
クライアントがオブジェクトを保存できるサーバーを構築しています。これらのオブジェクトはクライアント側で完全に構築され、オブジェクトの存続期間全体にわたって永続的なオブジェクトIDを備えています。 クライアントがPUTを使用してオブジェクトを作成または変更できるように、APIを定義しました。 PUT /objects/{id} HTTP/1.1 ... {json representation of the object} {id}はオブジェクトIDであるため、Request-URIの一部です。 ここで、クライアントがPOSTを使用してオブジェクトを作成できるようにすることも検討しています。 POST /objects/ HTTP/1.1 ... {json representation of the object, including ID} POSTは「追加」操作を意図しているので、オブジェクトがすでにそこにある場合にどうすればよいかわかりません。リクエストを変更リクエストとして処理する必要がありますか、それともエラーコード（どちらか）を返す必要がありますか？
8
検証の失敗または無効な重複のREST HTTPステータスコード
RESTベースのAPIを使用してアプリケーションを構築していて、各リクエストのステータスコードを指定するようになりました。 検証に失敗したリクエスト、またはリクエストがデータベースに重複を追加しようとしている場合、どのステータスコードを送信する必要がありますか？ http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlを確認しましたが、どれも正しくないようです。 ステータスコードを送信する際の一般的な方法はありますか？
7
検証エラーに対してREST APIサービスによって返される適切なHTTPステータスコードは何ですか？
Django / PistonベースのREST APIアプリケーションで検証エラーが発生するたびに、現在401 Unauthorizedを返しています。見ていたたHTTPステータスコードレジストリ Iをy'allのは何をお勧めします、これは検証の失敗のために適切なコードであることを確信していませんよ？ 400不正な要求 401無許可 403禁止します 405メソッドは許可されていません 406受け入れ不可 412前提条件が失敗しました 417予想に失敗しました 422処理できないエンティティ 424失敗した依存関係 更新：上記の「検証エラー」とは、アプリケーションレベルのデータ検証エラーを意味します。つまり、誤って指定された日時、偽のメールアドレスなどです。
9
データのPOSTに対する400対422の応答
私が取り組んでいる「RESTのような」APIを使用して、さまざまなシナリオで返される正しいステータスコードを把握しようとしています。JSON形式でPOSTで購入できるエンドポイントがあるとします。次のようになります。 { "account_number": 45645511, "upc": "00490000486", "price": 1.00, "tax": 0.08 } クライアントが（予想される「税金」の代わりに）「sales_tax」を送った場合、何を返却すればよいですか。現在、私は400を返します。しかし、私はこれについて自分自身に質問し始めました。本当に422を返す必要がありますか？つまり、JSON（これはサポートされています）であり、有効なJSONです。必要なフィールドのすべてが含まれているわけではありません。
14
JAX-RS — JSONとHTTPステータスコードを一緒に返す方法は？
REST Webアプリ（NetBeans 6.9、JAX-RS、TopLink Essentials）を書いていて、JSON および HTTPステータスコードを返そうとしています。HTTP GETメソッドがクライアントから呼び出されたときにJSONを返すコードの準備ができて機能しています。基本的に： @Path("get/id") @GET @Produces("application/json") public M_機械 getMachineToUpdate(@PathParam("id") String id) { // some code to return JSON ... return myJson; } しかし、JSONデータと共にHTTPステータスコード（500、200、204など）も返したいと思います。 私が使用しようとしましたHttpServletResponse： response.sendError("error message", 500); しかし、これによりブラウザはそれを「本物の」500であると考え、出力Webページは通常のHTTP 500エラーページでした。 HTTPステータスコードを返して、クライアント側のJavaScriptがそれに依存するロジックを処理できるようにします（たとえば、HTMLページにエラーコードとメッセージを表示します）。これは可能ですか、またはHTTPステータスコードをそのようなものに使用しないでください。
13
Web APIコントローラーからhttpステータスコードを返す
Web APIコントローラーのGETメソッドで変更されていない304のステータスコードを返そうとしています。 私が成功した唯一の方法は次のようなものでした： public class TryController : ApiController { public User GetUser(int userId, DateTime lastModifiedAtClient) { var user = new DataEntities().Users.First(p => p.Id == userId); if (user.LastModified <= lastModifiedAtClient) { throw new HttpResponseException(HttpStatusCode.NotModified); } return user; } } ここでの問題は、これは例外ではなく、変更されていないため、クライアントキャッシュに問題がないことです。私はまた、戻り値の型がユーザーである必要があります（すべてのWeb APIの例がGETで示されているように）HttpResponseMessageまたはこのようなものを返しません。
5
HTTPステータスコード200（キャッシュ）とステータスコード304の違いは何ですか？
FirefoxのGoogle "Page Speed"プラグインを使用してWebサイトにアクセスしています。 ページ上のコンポーネントの一部がHTTPステータスとして示されています。 200 200（キャッシュ）304 Googleの「ページ速度」。 私が混乱しているのは、200（キャッシュ）と304の違いです。 ページを複数回更新しました（ただし、キャッシュをクリアしていません）と、favicon.icoといくつかの画像がstatus = 200（キャッシュ）であるのに対し、他の一部の画像はhttpステータス304であるようです。 なぜその違いがわかりません。 更新： Googleの「ページスピード」を使用して、私はのために、「200（キャッシュ）」を受信http://example.com/favicon.icoなどhttp://cdn.example.com/js/ga.js しかし、http ：//cdn.example.com/js/combined.min.jsの httpステータス「304」を受け取ります 同じディレクトリ/ js /に2つのJavaScriptファイルがある理由がわかりません。1つはhttpステータス304を返し、もう1つは200（キャッシュ）ステータスコードを返します。
9
HttpResponseExceptionをスローするか、Request.CreateErrorResponseを返しますか？
ASP.NET Web APIでの例外処理の記事を確認した後、例外をスローするタイミングとエラーレスポンスを返すタイミングについて少し混乱しています。メソッドがドメイン固有のモデルではなくHttpResponseMessage...を返すときに応答を変更できるかどうかも疑問に思っています。 だから、ここで要約すると、私の質問の後にケース番号付きのコードが続きます： ご質問 ケース＃1に関する質問 HttpResponseMessageメッセージをカスタマイズできるように、具体的なドメインモデルではなく常に使用する必要がありますか？ 具体的なドメインモデルを返す場合、メッセージをカスタマイズできますか？ ケース＃2、3、4に関する質問 例外をスローするか、エラー応答を返す必要がありますか？答えが「依存する」である場合、どちらを使用するかについて状況/例を挙げられますか。 投げHttpResponseExceptionvs はどう違いRequest.CreateErrorResponseますか？クライアントへの出力は同じようです... HttpErrorエラーに応答メッセージを「ラップ」するために常に使用する必要がありますか（例外がスローされるか、エラー応答が返されるか）。 ケースサンプル // CASE #1 public Customer Get(string id) { var customer = _customerService.GetById(id); if (customer == null) { var notFoundResponse = new HttpResponseMessage(HttpStatusCode.NotFound); throw new HttpResponseException(notFoundResponse); } //var response = Request.CreateResponse(HttpStatusCode.OK, customer); //response.Content.Headers.Expires = new DateTimeOffset(DateTime.Now.AddSeconds(300)); return …
11
HTTPエラーコードを指定する方法
私が試してみました： app.get('/', function(req, res, next) { var e = new Error('error message'); e.status = 400; next(e); }); そして： app.get('/', function(req, res, next) { res.statusCode = 400; var e = new Error('error message'); next(e); }); ただし、常にエラーコード500が通知されます。
8
REST APIで「まだ準備ができていません。後でもう一度やり直してください」のHTTPステータスコードを選択するには [閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 この質問を改善する 私はhttp://server/thingyapi/thingyblob/1234、ダウンロードするもの1234に関連付けられたファイル（別名「blob」）を返すRESTful APIを開発しています。ただし、サーバーにファイルが存在しないときに要求が行われた可能性がありますが、後で確実に使用できるようになります。サーバーには、すべてのもののすべてのblobを生成するバッチプロセスがあります。Thingy 1234はすでに存在し、Blob以外のそのデータはすでに利用可能です。サーバーは、まだ1234のblobを生成する必要がありません。 404を返したくありません。それは存在しないもののためのものです。これは存在するものですが、そのBLOBはまだ生成されていません。ちょっと「処理中」のYouTube動画が好きです。リダイレクトコードも適切だとは思いません。試す「他の」URLはありません。 このような場合に返される正しいHTTPステータスコードは何ですか？
2
HTTPリダイレクトコードの違い
さまざまなHTTP 3XXリダイレクトコードの違いは明確ではありません。はい、私は仕様を読みましたが、ここでは標準と実際の実践との間にいくつかの矛盾があるようです。 301リダイレクトコードは明らかに十分なようだ：リソースが恒久的に別のURIに移動されました。この手段を、そして未来の要求はURIことを使用する必要があります。 また、307リダイレクトコードも明確に見えます。つまり、リダイレクトは一時的なものであり、今後のリクエストでは引き続き元のURIを使用する必要があります。 しかし、私は違いが間にあるものを言うことができない302と303、あるいはそれらのいずれかから、本当に異なっている理由301。302もともとは一時的なリダイレクト（のような307）を意図していたようですが、実際には、ほとんどのブラウザはのように処理していました303。しかし、a 303とaの違いは何301ですか？される301リダイレクトがあることを意味することになって、より恒久的な？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.