Mã trạng thái http cho Dịch vụ trên mạng không có sẵn trong khu vực của bạn là gì?

Dịch vụ của chúng tôi là ở 5 thành phố ngay bây giờ. Nếu ai đó cố gắng gọi API dịch vụ của chúng tôi từ bất kỳ thành phố nào khác, chúng tôi muốn đưa ra lỗi này Service not available in your area.

Câu hỏi là, mã http thích hợp sẽ là gì cho lỗi này?

• Lỗi 503: Dịch vụ không khả dụng
• 403: Cấm

hay cái gì khác?

Bất kỳ mã lỗi HTTP sẽ không phù hợp. Không có lỗi hoặc vấn đề thuộc bất kỳ loại nào từ phối cảnh HTTP, vì vậy nó phải là một cái gì đó trong phạm vi 200. Bạn lịch sự thông báo cho một số người dùng của bạn rằng họ sẽ không được phục vụ bằng cách gửi lại tài liệu cho họ biết như vậy. Và tất cả điều này diễn ra tốt đẹp.

Người dùng sẽ không thể sử dụng ứng dụng của bạn . Đó là một quyết định có ý thức được đưa ra bởi logic kinh doanh của bạn, không phải là một rủi ro. Ở cấp độ HTTP, mọi thứ đều tuyệt vời.

Biên tập

Có vẻ như những gì chúng ta đang xem xét ở đây là sự xung đột giữa trường học cũ và trường học mới. Khi HTTP được thiết kế, không có dịch vụ web, không có SOAP, không có JSON, không có nguyên tắc REST. Là một giao thức trên TCP, điều này đã được xem xét (gần với) cấp độ ứng dụng và nhiều mã trạng thái cấp cao đã được xác định. Khi web bắt đầu được sử dụng cho các dịch vụ phong phú hơn, mức độ cao hơn và phương tiện phổ biến để vận chuyển "phong bì" là bắt buộc, các nhà thiết kế đã sử dụng HTTP thay vì xác định giao thức mới hơn và sạch hơn, chỉ vì HTTP có mặt ở khắp mọi nơi.

Vì vậy, trong bối cảnh dịch vụ web hiện đại, HTTP thực sự ít hơn một lớp vận chuyển ngu ngốc và hầu hết các mã của nó có thể được coi là không áp dụng hoặc lỗi thời. Chỉ cần chọn một vì nó gần với trạng thái ứng dụng của bạn và tình cờ nằm ​​trong danh sách đó có nghĩa là một cái gì đó có vẻ vô hại, nhưng tôi nghĩ rằng nó sẽ gửi một thông điệp sai. Bạn không muốn HTTP đóng vai trò điều tiết đó trong ngữ cảnh dịch vụ web.

5xxlỗi là lỗi máy chủ - đã xảy ra lỗi trên máy chủ. Cụ thể, 503 chỉ ra rằng:

máy chủ hiện không thể xử lý yêu cầu do quá tải tạm thời hoặc bảo trì theo lịch trình

4xxlỗi là lỗi máy khách - máy khách đang yêu cầu máy chủ không thể hoặc không muốn thực hiện. Cụ thể, 403 chỉ ra rằng

máy chủ hiểu yêu cầu nhưng từ chối ủy quyền. Một máy chủ muốn công khai lý do tại sao yêu cầu bị cấm có thể mô tả lý do đó trong tải trọng phản hồi (nếu có). [..] Tuy nhiên, một yêu cầu có thể bị cấm vì những lý do không liên quan đến thông tin đăng nhập.

Tôi cho rằng điều đó 503rõ ràng không chính xác, bởi vì đây không phải là vấn đề tạm thời - bạn không hỗ trợ các yêu cầu trong khu vực đó, giai đoạn đó. Đối số có thể được đưa ra là cuối cùng bạn hy vọng hỗ trợ khu vực, nhưng mục đích của mã là bao gồm một tiêu đề cho biết khi nào khách hàng có thể thử lại. "Trong 6 tháng" không tuân thủ ý định.

403 là một lựa chọn tốt hơn vì dịch vụ của bạn chỉ đơn giản là cấm các yêu cầu từ một số địa phương nhất định.

Không phải của những người đó.

Nếu API của bạn được thiết kế tốt, URL sẽ bao gồm tên của thành phố, ví dụ:

http://example.com/API/Vienna/HailRide

hoặc là

http://example.com/API/HailRide?city=Vienna

do định vị địa lý IP không đáng tin cậy, người dùng của bạn có thể đang sử dụng VPN, người dùng của bạn có thể muốn đi nhờ người khác, v.v. Đề xuất một thành phố dựa trên vị trí của người dùng là trách nhiệm của khách hàng API . Thông thường, khách hàng có nhiều tài nguyên tốt hơn để xác định vị trí của người dùng (ví dụ: dịch vụ vị trí của thiết bị di động).

Khi bạn đã thực hiện điều đó, câu trả lời chính xác cho

http://example.com/API/SomeUnsupportedCity/HailRide

hoặc là

http://example.com/API/HailRide?city=SomeUnsupportedCity

trở nên rõ ràng: 404 Không tìm thấy : Không có tài nguyên cho việc đi xe tại một sốUnsupportedCity tồn tại.

Điều này có vẻ như một câu hỏi lỗ tròn / chốt vuông. Tại sao phản hồi duy nhất của bạn cần phải là mã HTTP? Mã lỗi HTTP không thể bao gồm tất cả các trường hợp sử dụng.

Tất cả các cuộc gọi API của bạn sẽ có thêm thông báo quay lại - tức là một thông báo lỗi JSON nhỏ. Cung cấp cho họ 403 (vì thực sự họ không có quyền sử dụng API được cung cấp vị trí) và trả lại một chút thông tin như bạn đang đề xuất.

Nếu bạn không làm điều này thì lần sau bạn sẽ hỏi mã lỗi HTTP nào sẽ trả về khi người dùng yêu cầu một chiếc SUV nhưng chỉ có một chiếc Prius có sẵn.

Một số ít có ý nghĩa.

403 Bị cấm, vì những lý do mà Eric Stein đề cập trong câu trả lời của mình . Bạn có thể sử dụng nhiều thông tin khác nhau được cung cấp bởi yêu cầu để xác định vị trí của khách hàng và khách hàng là ai và, dựa trên yêu cầu đó, máy chủ không thể hoặc không sẵn lòng phản hồi.

Tuy nhiên, tôi cũng sẽ đưa ra 451 Không có sẵn cho các lý do pháp lý như một trạng thái trả lại có thể cho một số trường hợp. Trạng thái này không mong đợi bạn bao gồm (trong các tiêu đề) một liên kết đến pháp luật có liên quan. Nó đặc biệt dành cho các trường hợp khách hàng truy cập tài nguyên của bạn không hợp pháp và không phải là trường hợp chung hơn của khách hàng tồn tại ở khu vực hoặc khu vực không được hỗ trợ.

Tôi sẽ tránh các loạt trạng thái 5xx - những trạng thái này thường chỉ ra các vấn đề kỹ thuật phía máy chủ. Nó không xuất hiện ở đây.

Nếu hạn chế là do lý do pháp lý, thì mã lỗi HTTP thích hợp là HTTP 451, "Không khả dụng do lý do pháp lý."

Điều này thường được sử dụng trong trường hợp tài liệu đã bị thu hồi do hành động hoặc vụ kiện DMCA do các chiến dịch quấy rối hoặc tương tự, nhưng tinh thần và thư của định nghĩa phản hồi nêu rõ:

Tài liệu này chỉ định mã trạng thái Giao thức truyền siêu văn bản (HTTP) để sử dụng khi quyền truy cập tài nguyên bị từ chối do hậu quả của nhu cầu pháp lý.

Bản thân mã này là một tham chiếu đến Fahrenheit 451 của Ray Bradbury.

Mọi người thường quên rằng mã trạng thái HTTP có thể mở rộng.

Mã trạng thái HTTP có thể mở rộng. Các ứng dụng HTTP không bắt buộc phải hiểu ý nghĩa của tất cả các mã trạng thái đã đăng ký, mặc dù hiểu rõ như vậy rõ ràng là mong muốn. Tuy nhiên, các ứng dụng PHẢI hiểu lớp của bất kỳ mã trạng thái nào, như được chỉ ra bởi chữ số đầu tiên và coi bất kỳ phản hồi không được nhận dạng nào tương đương với mã trạng thái x00 của lớp đó, ngoại trừ phản hồi không được nhận dạng PHẢI KHÔNG được lưu vào bộ nhớ cache. Ví dụ: nếu khách hàng nhận được mã trạng thái không được nhận dạng là 431, thì có thể giả định rằng có yêu cầu sai với yêu cầu của mình và xử lý phản hồi như thể đã nhận được 400 mã trạng thái. Trong các trường hợp như vậy, tác nhân người dùng NÊN trình bày cho người dùng thực thể được trả về với phản hồi,

https://tools.ietf.org/html/rfc2616#section-6.1.1

Bạn luôn có thể tạo mã trạng thái của riêng mình trong phạm vi 400 để sử dụng bởi ứng dụng khách và API của bạn.

Lúc đầu, tôi nghĩ 503 vì mô tả "dịch vụ không khả dụng" có vẻ phù hợp với vấn đề nhưng nhìn vào các định nghĩa , 503 thực sự cụ thể đối với sự không có sẵn của máy chủ. Sau đó suy nghĩ nhiều hơn, bạn đang nói với khách hàng rằng có một vấn đề với yêu cầu, không phải là có vấn đề về phía máy chủ.

403 gần hơn vì bạn đang nói với người dùng rằng bạn đã nhận được tin nhắn và hiểu nó nhưng máy chủ không sẵn lòng đáp ứng. Điều này có thể gây nhầm lẫn để có thể thêm một lời giải thích bằng văn bản để mô tả kịch bản. Theo RFC, 404 cũng là một thay thế hợp lệ cho mã này.

Trừ khi ai đó đã mơ thấy một mã mới cho điều này, 403 hoặc 404 dường như là gần nhất.

Bạn phải khớp mô tả lỗi với mã mà bạn đang đưa ra:

• nếu bạn nói Service not available in your area.thì bạn nên đưa ra 404vì bạn cho rằng dịch vụ này không có sẵn .

• nếu bạn nói You are not authorized for this service in your area.thì bạn nên đưa ra 403vì bạn cho rằng người gọi không được ủy quyền .

Tôi sẽ đi lần thứ hai.

Có một Dự thảo Internet hiện tại (sẽ hết hạn vào ngày 31 tháng 12 năm 2018) đề xuất sửa đổi đối với HTTP 451 Không khả dụng cho tình trạng Lý do pháp lý . Dự thảo đề xuất rằng phản hồi 451 phải chứa một geo-scope-blocktiêu đề "tương ứng với danh sách mã quốc gia alpha-2 được phân tách bằng dấu phẩy được xác định trong [ISO.3166-1]". Tuy nhiên, dự thảo cũng chỉ rõ rằng mã 451 không nên được sử dụng "bởi nhà điều hành để từ chối quyền truy cập vào tài nguyên trên cơ sở chính sách được chỉ định bởi nhà điều hành (trái ngược với yêu cầu pháp lý được đặt trên nhà điều hành)".

Vì vậy, giả sử bạn không có nhu cầu hợp pháp cho geoblock, 451 không phải là mã chính xác. Mã chính xác là gì sau đó? Chà, rất nhiều câu trả lời khác đã đề xuất 403 Bị cấm , nhưng tất cả chúng dường như là "dựa trên ý kiến", vì vậy hãy xem những gì người khác đang làm:

• Amazon CloudFront sử dụng 403 Cấm
• Twitter rõ ràng trả về 200 OK nhưng giải thích vấn đề trong nội dung JSON - nhưng đó là cho các tweet riêng lẻ, không phải toàn bộ API
• Pinterest sử dụng 451
• Plugin WordPress IP Geo Block cho phép bạn chọn bất kỳ mã hiện có nào

Vì vậy, không có một giải pháp phổ quát nào, bạn sẽ phải chọn một giải pháp mà bạn cảm thấy phù hợp nhất với tình huống của mình. Nhưng cho dù bạn chọn cách nào, hãy chắc chắn giải thích vấn đề thực tế trong phần phản hồi .

Tôi muốn nói rằng sẽ không có gì sai khi chỉ định mã trạng thái HTTP tùy chỉnh, như RubberDuck đã trả lời . Mã trạng thái tùy chỉnh trong phạm vi 400 thực sự thậm chí có thể là một cuộc gọi khá tốt, bởi vì điều đó chắc chắn sẽ thu hút sự chú ý của các nhà phát triển nếu họ thấy một cái gì đó như "trạng thái HTTP 499". "403" quá dễ để vượt qua là " OK vì vậy tôi đã nhầm mật khẩu của mình, thay vào đó hãy thử một cái gì đó khác " và điều đó dẫn đến lãng phí hàng giờ.