Mã lỗi gần như là thứ cuối cùng bạn muốn thấy trong phản hồi API. Nói chung, nó có nghĩa là một trong hai điều – có gì đó sai trong yêu cầu của bạn hoặc cách xử lý của bạn đến mức API không thể phân tích cú pháp dữ liệu được truyền hoặc bản thân API có quá nhiều vấn đề đến nỗi ngay cả yêu cầu được hình thành tốt nhất cũng sẽ xảy ra thất bại. Trong cả hai tình huống, lượng traffic dừng lại và quá trình tìm ra nguyên nhân và giải pháp bắt đầu.
Xem thêm: 6 mẹo bán hàng online đắt khách, 99% người kinh doanh không biết
Các lỗi, cho dù ở dạng mã hay phản hồi lỗi đơn giản, giống như một cú đánh khó chịu, nhưng cực kỳ hữu ích. Mã lỗi có lẽ là yếu tố chẩn đoán hữu ích nhất trong không gian API và điều này thật đáng ngạc nhiên, do chúng ta thường ít chú ý đến chúng.
Hôm nay, Wikitinhoc.net sẽ nói về lý do chính xác tại sao phản hồi lỗi và các phương pháp xử lý lại hữu ích và quan trọng đến vậy. Chúng tôi sẽ xem xét một số phân loại mã lỗi phổ biến mà người dùng bình thường sẽ gặp phải, cũng như một số ví dụ về các mã này trong thực tế.
1. Giá trị của mã lỗi
Như chúng tôi đã nói, mã lỗi cực kỳ hữu ích. Mã lỗi trong giai đoạn phản hồi của API là cách cơ bản mà nhà phát triển có thể thông báo lỗi cho người dùng. Giai đoạn này, sau giai đoạn yêu cầu ban đầu, là giao tiếp trực tiếp giữa ứng dụng khách và API. Đây thường là bước đầu tiên và quan trọng nhất để không chỉ thông báo cho người dùng về lỗi mà còn bắt đầu ngay quá trình giải quyết lỗi.
Người dùng không chọn thời điểm tạo ra lỗi hoặc lỗi nào mắc phải – các tình huống lỗi thường phát sinh trong các trường hợp mà đối với người dùng, là hoàn toàn ngẫu nhiên và đáng ngờ. Do đó, các phản hồi lỗi là thông tin liên lạc thực sự ổn định và duy nhất mà người dùng có thể phụ thuộc vào khi có lỗi xảy ra. Mã lỗi có giá trị ngụ ý theo cách chúng vừa làm rõ tình huống vừa truyền đạt chức năng dự kiến .
Ví dụ, hãy xem xét một mã lỗi như “401 Unauthorized – Please Pass Token”. Trong một phản hồi như vậy, bạn hiểu điểm thất bại, cụ thể là người dùng không được phép. Ngoài ra, bạn phát hiện ra chức năng dự định – API yêu cầu mã thông báo và mã thông báo đó phải được chuyển như một phần của yêu cầu để được cấp quyền.
Với một mã lỗi đơn giản và giải thích cách giải quyết, bạn không chỉ truyền đạt được nguyên nhân gây ra lỗi mà còn cả chức năng và phương pháp dự định để sửa lỗi đã nói – điều đó cực kỳ có giá trị, đặc biệt là đối với lượng dữ liệu thực sự được trả về.
2. Các mã trạng thái HTTP
Trước khi tìm hiểu sâu hơn về mã lỗi và điều gì làm cho mã “tốt” là “tốt”, chúng ta cần giải quyết định dạng Mã trạng thái HTTP. Những mã này là mã trạng thái phổ biến nhất mà người dùng bình thường sẽ gặp phải, không chỉ về API mà còn về việc sử dụng internet nói chung. Trong khi các giao thức khác tồn tại và có hệ thống mã riêng của chúng, Mã trạng thái HTTP chiếm ưu thế trong giao tiếp API và các mã dành riêng cho nhà cung cấp có thể bắt nguồn từ các phạm vi này.
2.1. 1XX – Thông tin
Phạm vi 1XX có hai chức năng cơ bản. Đầu tiên là trong việc chuyển giao thông tin liên quan đến trạng thái giao thức của các thiết bị được kết nối – ví dụ: 101 Switching Protocols là một mã trạng thái cho biết khách hàng đã yêu cầu thay đổi giao thức từ máy chủ và yêu cầu đã được chấp thuận. Phạm vi 1XX cũng làm rõ trạng thái của yêu cầu ban đầu. 100 Continue, ví dụ, lưu ý rằng máy chủ đã nhận được tiêu đề yêu cầu từ máy khách và máy chủ đang chờ nội dung yêu cầu.
2.2. 2XX – Thành công
Phạm vi 2XX ghi nhận một loạt thành công trong giao tiếp và đóng gói một số phản hồi thành các mã cụ thể. Ba mã trạng thái đầu tiên thể hiện hoàn hảo phạm vi này – 200 OK có nghĩa là một yêu cầu GET hoặc POST đã thành công, 201 Created xác nhận rằng một yêu cầu đã được thực hiện và một tài nguyên mới đã được tạo cho khách hàng và 202 Accepted có nghĩa là yêu cầu đã được chấp nhận và quá trình xử lý đã bắt đâu.
2.3. 3XX – Chuyển hướng
Phạm vi 3XX là tất cả về trạng thái của tài nguyên hoặc điểm cuối. Khi loại mã trạng thái này được gửi đi, điều đó có nghĩa là máy chủ vẫn đang chấp nhận giao tiếp, nhưng điểm được tiếp xúc không phải là điểm nhập chính xác vào hệ thống. 301 Moved Permanently xác minh rằng yêu cầu của máy khách trên thực tế đã đến đúng hệ thống, nhưng yêu cầu này và tất cả các yêu cầu trong tương lai phải được xử lý bởi một URI khác. Điều này rất hữu ích trong các miền phụ và khi di chuyển tài nguyên từ máy chủ này sang máy chủ khác.
2.4. 4XX – Lỗi máy khách
Chuỗi mã lỗi 4XX có lẽ là nổi tiếng nhất do 404 Not Found trạng thái mang tính biểu tượng, đây là điểm đánh dấu nổi tiếng cho các URL và URI được định dạng không chính xác. Tuy nhiên, các mã trạng thái hữu ích hơn cho API tồn tại trong phạm vi này.
414 URI Too Long là mã trạng thái phổ biến, biểu thị rằng dữ liệu được đẩy qua trong một yêu cầu GET quá dài và phải được chuyển đổi thành một yêu cầu ĐĂNG. Một mã phổ biến khác là 429 Too many Requests, được sử dụng để giới hạn tốc độ để lưu ý rằng khách hàng đang cố gắng thực hiện quá nhiều yêu cầu cùng một lúc và lưu lượng truy cập của họ đang bị từ chối.
2.5. 5XX – Lỗi máy chủ
Cuối cùng, phạm vi 5XX được dành riêng cho các mã lỗi liên quan cụ thể đến chức năng máy chủ. Trong khi phạm vi 4XX là trách nhiệm của máy khách (và do đó biểu thị lỗi máy khách), phạm vi 5XX ghi chú cụ thể các lỗi với máy chủ. Các mã lỗi như 502 Bad Gateway, ghi chú rằng máy chủ ngược dòng đã bị lỗi và máy chủ hiện tại là một cổng vào, tiếp tục hiển thị chức năng của máy chủ như một phương tiện hiển thị nơi xảy ra lỗi. Cũng có những hư hỏng chung chung, ít cụ thể hơn, chẳng hạn như 503 Service Unavailable.