คำถามติดแท็ก http-status-codes

รหัสสถานะ HTTP คือชุดของรหัสมาตรฐานที่ส่งคืนในการตอบกลับเว็บ HTTP คำถามเกี่ยวกับสาเหตุที่บริการ (โดยไม่คาดคิด) ส่งคืนรหัสสถานะไม่ควรใช้แท็กนี้

17
403 ต้องห้าม vs 401 การตอบกลับ HTTP ที่ไม่ได้รับอนุญาต
สำหรับหน้าเว็บที่มีอยู่ แต่ผู้ใช้ไม่มีสิทธิ์เพียงพอ (ไม่ได้ล็อกอินหรือไม่ได้อยู่ในกลุ่มผู้ใช้ที่เหมาะสม) การตอบสนอง HTTP ที่เหมาะสมในการแสดงคืออะไร? 401 Unauthorized? 403 Forbidden? อื่น ๆ อีก? สิ่งที่ฉันได้อ่านมาจนถึงตอนนี้ยังไม่ชัดเจนในความแตกต่างระหว่างสองอย่างนี้ กรณีการใช้งานใดที่เหมาะสมสำหรับการตอบกลับแต่ละครั้ง


14
รหัสตอบกลับ HTTP สำหรับ POST เมื่อทรัพยากรมีอยู่แล้ว
ฉันกำลังสร้างเซิร์ฟเวอร์ที่อนุญาตให้ลูกค้าจัดเก็บวัตถุ วัตถุเหล่านั้นถูกสร้างอย่างสมบูรณ์ที่ฝั่งไคลเอ็นต์พร้อมด้วย ID วัตถุที่ถาวรตลอดอายุการใช้งานของวัตถุ ฉันได้กำหนด API เพื่อให้ลูกค้าสามารถสร้างหรือปรับเปลี่ยนวัตถุโดยใช้ PUT: 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 สำหรับการตรวจสอบที่ล้มเหลวหรือซ้ำกันไม่ถูกต้อง
ฉันกำลังสร้างแอปพลิเคชันด้วย API ที่ใช้ REST และมาถึงจุดที่ฉันระบุรหัสสถานะสำหรับแต่ละคำขอ ฉันควรส่งรหัสสถานะใดสำหรับคำร้องขอที่ไม่ผ่านการตรวจสอบความถูกต้องหรือที่คำขอกำลังพยายามเพิ่มซ้ำในฐานข้อมูลของฉัน ฉันได้ตรวจสอบhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlแต่ดูเหมือนว่าไม่มีสิ่งใดถูกต้อง มีวิธีปฏิบัติทั่วไปเมื่อส่งรหัสสถานะหรือไม่

7
รหัสสถานะ HTTP ที่เหมาะสมในการส่งคืนโดยบริการ REST API สำหรับการตรวจสอบความล้มเหลวคืออะไร
ปัจจุบันฉันกลับ 401 ไม่ได้รับอนุญาตเมื่อใดก็ตามที่ฉันประสบความล้มเหลวในการตรวจสอบความถูกต้องในแอปพลิเคชัน RANG API ของDjango / Pistonของฉัน เมื่อดูที่HTTP Status Code Registry ฉันไม่มั่นใจว่านี่เป็นรหัสที่เหมาะสมสำหรับการตรวจสอบความล้มเหลวคุณควรแนะนำอะไร 400 คำขอไม่ถูกต้อง 401 ไม่ได้รับอนุญาต 403 ต้องห้าม ไม่อนุญาตให้ใช้วิธี 405 406 ไม่เป็นที่ยอมรับ 412 เงื่อนไขเบื้องต้นล้มเหลว 417 ความคาดหวังล้มเหลว 422 เอนทิตีที่ไม่สามารถประมวลผลได้ 424 การพึ่งพาล้มเหลว อัปเดต : "การตรวจสอบความล้มเหลว" ด้านบนหมายถึงความล้มเหลวในการตรวจสอบความถูกต้องของข้อมูลระดับแอปพลิเคชันเช่นวันที่และเวลาที่ระบุไม่ถูกต้องที่อยู่อีเมลปลอมเป็นต้น


9
400 vs 422 การตอบสนองต่อ POST ของข้อมูล
ฉันกำลังพยายามหารหัสสถานะที่ถูกต้องที่จะกลับมาในสถานการณ์ที่แตกต่างด้วย API "คล้ายกับ REST" ที่ฉันกำลังทำงานอยู่ สมมติว่าฉันมีจุดสิ้นสุดที่อนุญาตให้มีการซื้อ POST ในรูปแบบ JSON ดูเหมือนว่านี้: { "account_number": 45645511, "upc": "00490000486", "price": 1.00, "tax": 0.08 } ฉันควรส่งคืนอะไรถ้าลูกค้าส่ง "sales_tax" ให้ฉัน (แทนที่จะเป็น "ภาษี" ที่คาดหวัง) ปัจจุบันฉันส่งคืน 400 แต่ฉันเริ่มตั้งคำถามกับตัวเอง ฉันควรจะส่งคืน 422 หรือไม่ ฉันหมายถึงมันคือ JSON (ซึ่งได้รับการสนับสนุน) และเป็น JSON ที่ถูกต้อง แต่มันไม่ได้มีฟิลด์ที่จำเป็นทั้งหมด

14
JAX-RS - วิธีคืนรหัสสถานะ JSON และ HTTP ด้วยกันได้อย่างไร
ฉันกำลังเขียนแอปเว็บ REST (NetBeans 6.9, JAX-RS, TopLink Essentials) และพยายามส่งคืนรหัสสถานะJSON และ HTTP ฉันมีโค้ดที่พร้อมใช้งานและส่งคืน JSON เมื่อเมธอด HTTP GET ถูกเรียกใช้จากไคลเอ็นต์ เป็นหลัก: @Path("get/id") @GET @Produces("application/json") public M_機械 getMachineToUpdate(@PathParam("id") String id) { // some code to return JSON ... return myJson; } แต่ผมยังต้องการที่จะกลับรหัสสถานะ HTTP (500, 200, 204, ฯลฯ ) พร้อมกับข้อมูล JSON ฉันพยายามใช้HttpServletResponse: response.sendError("error message", 500); แต่สิ่งนี้ทำให้เบราว์เซอร์คิดว่าเป็น …

13
การส่งคืนรหัสสถานะ http จากตัวควบคุม Web Api
ฉันกำลังพยายามส่งคืนรหัสสถานะ 304 ที่ไม่ได้แก้ไขสำหรับวิธีการ GET ในตัวควบคุมเว็บ api วิธีเดียวที่ฉันประสบความสำเร็จคือสิ่งนี้: 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; } } ปัญหาที่นี่คือมันไม่ใช่ข้อยกเว้นมันไม่ได้ถูกแก้ไขดังนั้นแคชของลูกค้าก็โอเค ฉันต้องการให้ประเภทการคืนเป็นผู้ใช้ด้วย (เนื่องจากเว็บ api ทุกตัวอย่างแสดงด้วย GET) ไม่ส่งคืน HttpResponseMessage …

5
รหัสสถานะ HTTP 200 (แคช) กับรหัสสถานะ 304 ต่างกันอย่างไร
ฉันใช้ปลั๊กอิน "Page Speed" ของ Google สำหรับ Firefox เพื่อเข้าถึงเว็บไซต์ของฉัน ส่วนประกอบบางอย่างในหน้าของฉันถูกระบุว่าเป็นสถานะ HTTP: 200 200 (แคช) 304 ด้วย "ความเร็วหน้า" ของ Google สิ่งที่ฉันสับสนคือความแตกต่างระหว่าง 200 (แคช) กับ 304 ฉันรีเฟรชหน้าเว็บหลายครั้ง (แต่ยังไม่ได้ล้างแคช) และดูเหมือนว่า favicon.ico ของฉันและภาพไม่กี่ภาพจะเป็นสถานะ = 200 (แคช) ในขณะที่ภาพอื่น ๆ เป็นสถานะ http 304 ฉันไม่เข้าใจว่าทำไมถึงแตกต่าง อัปเดต : ใช้ Google "Page Speed" ฉันได้รับ "200 (แคช)" สำหรับhttp://example.com/favicon.icoรวมถึงhttp://cdn.example.com/js/ga.js แต่ฉันได้รับสถานะ http "304" …

9
โยน HttpResponseException หรือส่งคืน Request สร้าง CreateErrorResponse ไหม?
หลังจากตรวจสอบข้อยกเว้นการจัดการบทความใน ASP.NET Web APIฉันสับสนนิดหน่อยว่าเมื่อใดที่จะโยนข้อยกเว้น vs ส่งคืนการตอบกลับข้อผิดพลาด ฉันยังสงสัยว่ามันเป็นไปได้ที่จะปรับเปลี่ยนการตอบสนองเมื่อวิธีการของคุณส่งคืนรูปแบบเฉพาะโดเมนแทนHttpResponseMessage... ดังนั้นการสรุปที่นี่คำถามของฉันตามด้วยรหัสบางกรณี #s: คำถาม คำถามเกี่ยวกับ Case # 1 ฉันควรใช้HttpResponseMessageแทนโมเดลโดเมนที่เป็นรูปธรรมเสมอเพื่อให้สามารถปรับแต่งข้อความได้หรือไม่ สามารถปรับแต่งข้อความได้หรือไม่หากคุณส่งคืนโมเดลโดเมนที่เป็นรูปธรรม? คำถามเกี่ยวกับ Case # 2,3,4 ฉันควรจะโยนข้อยกเว้นหรือตอบกลับข้อผิดพลาด? หากคำตอบคือ "มันขึ้นอยู่กับ" คุณสามารถให้สถานการณ์ / ตัวอย่างเมื่อใดที่จะใช้หนึ่งเทียบกับอีก ความแตกต่างระหว่างการขว้างปาคืออะไรHttpResponseExceptionVS Request.CreateErrorResponse? ผลลัพธ์ไปยังลูกค้าดูเหมือนกัน ... ฉันควรจะใช้HttpErrorเพื่อ "ห่อ" ข้อความตอบสนองในข้อผิดพลาด (ไม่ว่าจะเป็นข้อยกเว้นโยนหรือการตอบกลับข้อผิดพลาด)? ตัวอย่างกรณี // CASE #1 public Customer Get(string id) { var customer = _customerService.GetById(id); if (customer == …

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
ฉันจะเลือกรหัสสถานะ HTTP ใน REST API สำหรับ“ ยังไม่พร้อมลองอีกครั้งในภายหลัง” ได้อย่างไร [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ปรับปรุงคำถามนี้ ฉันกำลังพัฒนา RESTful API ซึ่งhttp://server/thingyapi/thingyblob/1234ส่งคืนไฟล์ (หรือที่รู้จักว่า "blob") ที่เกี่ยวข้องกับ thingy # 1234 เพื่อดาวน์โหลด แต่อาจเป็นได้ว่ามีการร้องขอในเวลาที่ไฟล์ไม่มีอยู่ในเซิร์ฟเวอร์ แต่ส่วนใหญ่จะสามารถใช้งานได้ในภายหลัง มีกระบวนการแบทช์ในเซิร์ฟเวอร์ที่สร้าง blobs ทั้งหมดสำหรับทุกสิ่ง Thingy 1234 มีอยู่แล้วและมีข้อมูลอื่นนอกเหนือจาก blob แล้ว เซิร์ฟเวอร์ยังไม่ได้สร้างสิ่งที่เป็นก้อน 1234 ฉันไม่ต้องการกลับ 404; สำหรับสิ่งที่ไม่มีอยู่จริง นี่คือสิ่งที่มีอยู่ แต่หยดยังไม่ได้ถูกสร้างขึ้น ค่อนข้างชอบวิดีโอ 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.