Có một tiêu chuẩn cho các lỗi/mã lỗi tồn tại không?

Question

Tôi hiện đang viết một API/một số khách hàng cho trò chơi cờ vua.

Nhà phát triển nên truy cập API thông qua một tập lệnh (xhrframework.php) và gửi các tác vụ qua GET. Có thể họ mắc một số lỗi khi họ gửi các hành động (Không có PHPSESSID được gửi, không có PHPSESSID hợp lệ, di chuyển không hợp lệ, không phải là lượt của họ, ...).

Vì vậy, tôi đã suy nghĩ về các vị trí cách hiển thị lỗi. Tôi đã đưa ra một số ý tưởng làm thế nào để thông báo cho các lập trình viên, anh đã xây dựng một lỗi:

1. qua một thông báo lỗi trong rõ ràng tiếng anh
   • +: Rõ ràng những gì mà lỗi nên có nghĩa
   • + : Thông tin về cách sửa lỗi này có thể được thêm
   • -: Thông báo có thể thay đổi vì tiếng anh của tôi không tốt lắm
   • -: Độ dài của thông điệp rất khác nhau - điều này có thể quan trọng đối với lập trình viên C
2. qua ab liên tục thông báo lỗi bằng tiếng Anh - một cái gì đó giống như WRONG_PHPSESSID, MISSING_PHPSESSID, INVALID_MOVE, NOT_YOUR_TURN, ...
   • +: Đó là điều dễ hiểu đối với một con người
   • 0: Đó là gần như chắc chắn rằng thông điệp doesn 't thay đổi
   • -: chiều dài của thông điệp có thể khác nhau một chút
3. thông qua một mã lỗi với một bảng trong tài liệu mà các lập trình viên có thể tìm thấy ý nghĩa của các mã lỗi
   • +: Các mã lỗi sẽ được liên tục
   • +: Các chiều dài của tất cả các mã lỗi có thể là cùng một
   • -: Đó là bí ẩn

tôi thoguht giải pháp thứ ba có thể là một ý tưởng hay vì xhrframework.php chỉ nên được truy cập bởi một lập trình viên khá có thể đã xem xét tài liệu API.

Bây giờ tôi muốn biết liệu một tiêu chuẩn cho các thông báo lỗi Web-API có tồn tại hay không. Những người khác (ví dụ: API Google Maps) đã giải quyết vấn đề này như thế nào? Tôi có nên tạo một trang trống với nội dung "L ERI: 004" hoặc không có đệm "L ERI: 4" không?

Lỗi nào sẽ nhận số nào? Ist có ý nghĩa với các lỗi nhóm theo số của chúng hay không, ví dụ: tất cả các lỗi bắt đầu bằng 1 là lỗi xác thực, tất cả các lỗi có hai lỗi logic trò chơi? Nó sẽ là tốt hơn để bắt đầu với lỗi 1 và sử dụng từng số?

Google Maps API

Nếu tôi thực hiện một wrong call Google Maps JS-API, nó sẽ trả Java Script với một thông điệp rõ ràng ở Đức (như tôi sống ở Đức, tôi đoán).

API bản đồ tĩnh của Google trả lại tin nhắn dưới dạng văn bản bằng tiếng Anh rõ ràng nếu tôi tạo wrong call.

Answer 1

Hầu hết các dịch vụ API theo hệ thống HTTP mã lỗi RFC2817 với dãy mã lỗi với nhiều loại khác nhau của lỗi:

1xx: Informational - Request received, continuing process 
2xx: Success - The action was successfully received, understood, and accepted 
3xx: Redirection - Further action must be taken in order to complete the request 
4xx: Client Error - The request contains bad syntax or cannot be fulfilled 
5xx: Server Error - The server failed to fulfil an apparently valid request 

Trong một bối cảnh API bạn chủ yếu sẽ sử dụng các giá trị 4xx để biểu thị điều kiện lỗi để làm với xác nhận yêu cầu. 49x thường được sử dụng cho các điều kiện lỗi bảo mật.

Answer 2

Không có tiêu chuẩn và tại sao phải có? Các lập trình viên sử dụng giao diện của bạn đã phải học điều đó, có lẽ là một cái gì đó tùy chỉnh, vì vậy cần viết mã xử lý lỗi tùy chỉnh chỉ là một phần của gói.

Tôi khuyên bạn nên tạo một định dạng hợp lý mà bạn sẽ tuân theo. Bạn có thể đi với tốt nhất của mỗi thế giới và bao gồm một số mẩu thông tin trong những gì bạn quay trở lại, có lẽ cùng những dòng này:

[one of "ERROR" or "WARNING" or "MESSAGE"] 
[error code with no spaces, eg "BAD_MOVE"] 
[optional human readable string] 

Bằng cách đó, nếu một loại lỗi mới được phát minh ra rằng khách hàng cũ không hiểu, họ vẫn có thể nhận ra rằng sự trở lại bắt đầu bằng "L ERI" và biết rằng đã xảy ra sự cố; bằng cách phân tích cú pháp cho mã lỗi (không sử dụng số nguyên, nó là một sự lãng phí thời gian của mọi người), họ có thể thực hiện hành động thích hợp nếu đó là lỗi mà lập trình viên đã tính đến. Cuối cùng, nếu bạn đặt một chuỗi thân thiện cho các lỗi đã chọn, nó sẽ giúp bạn dễ dàng trình bày điều gì đó tốt đẹp cho người dùng hoặc hữu ích để gỡ lỗi.