Cách khắc phục lỗi error blank response from server năm 2024
Hồi còn đi làm, mấy ông anh trong công ty cứ chê CLB lập trình web ở trường mình cùi bắp, gà. Lúc đó mình cay lắm, nhưng giờ khi về lại đi học, mình nhận ra, nó còn gà hơn mình tưởng, có một số thứ basic, mà các bạn trong CLB đôi khi hiểu sai và sử dụng không đúng cách, và thế là mình quyết định viết blog này, với mục đích chia sẻ những kiến thức của mình về HTTP status và cách mà mình handle exception trong 1 số con app cá nhân. Bài viết này sẽ không đặt nặng quá nhiều về lập trình, mà nó nằm chung cho Web App sử dụng HTTP để request dữ liệu. Show Bài viết chỉ là ý kiến cá nhân, nếu thấy hợp lý, well, có thể làm theo mình, còn trong trường hợp bạn thấy nó vô lý, well, feedback ngay ở phần bình luận. Mã trạng thái phản hồi HTTP - HTTP Response Status codes?Về HTTP, nó ra đời cũng khá lâu rồi, nên cũng có khá nhiều bài viết nói về nó, nên để tìm hiểu về HTTP, giao thức HTTP là gì bạn có thể tìm hiểu thêm trên mạng? Hoặc tham khảo 1 số chỗ này:
Với các mã phản hồi của HTTP nó được phân ra làm 5 nhóm chính
Trên đây, là list 5 nhóm lỗi mà 1 yêu cầu HTTP có thể trả về cho client. Handle lỗi cho ứng dụngLúc mà mình đọc code của mấy bạn sinh viên ở CLB, thì mình nhận ra 1 số điều ngớ ngẩn, là các bạn đó sử dụng HTTP status 1 cách vô tội vạ. VD: "Mình có 1 API để tìm 1 sinh viên trong danh sách sinh viên của thư viên bằng MSSV (Mã số sinh viên). Thì thay vì bạn trả về 200 lúc tìm thấy, bạn lại trả về mã Trong 5 nhóm trạng thái kể trên, dễ thấy 1 điều là có 2 nhóm báo lỗi và 1 nhóm báo thành công. Đó là 2xx, 4xx và 5xx. Có 1 câu đùa vui của dev tụi mình lúc làm mấy cái API này là 400 là F*CK YOU, 500 LÀ F*CK ME. Handle lỗi với HTTP statusVới trường hợp thành công:Mình chỉ sử dụng 200 cho BẤT KỲ TRƯỜNG HỢP NÀO request thực hiện xong. Với trường hợp lỗi do client (F*CK YOU):
Với trường hợp lỗi do server (F*CK ME):
Với nhóm lỗi 5xx, vì là nhóm lỗi do server, nên thông thường, mình sẽ integrate nó với 1 ứng dụng bên thứ 3 để notify cho mình biết là server đang bị lỗi đó, vì những lỗi này làm break flow của user, mà nếu 1 người bị, thì sẽ có khả năng những người khác cũng sẽ bị, nên cần phải fix càng sớm càng tốt. Ngoài ra, có một điều lưu ý là 500 - Internal Server Error có nghĩa là nó bảo rằng server nó bug rồi, không làm gì được nữa cả. Đồng nghĩa, lúc mà bạn báo lỗi này ra cho client, thì có nghĩa, là app bạn đã chết rồi, không sử dụng được nữa, đó cũng là lý do tại sao trong 1 số UI template, người ta lại define trang 500, mà không có 501, hay 503,... Vì vậy, lúc phát triển các API thì Một số lỗi khác thì sao?Một số trường hợp bên ngoài, ví dụ như ứng dụng đang bảo trì,... thì làm sao, không có mã lỗi nào liên quan đến maintenance cả. Đơn giản thui, đâu ai cấm mình define lỗi mới đâu. Chỉ là không đụng chạm với status hiện tại là được mà, vì lúc thông báo bảo trì, thì phía client cần chuyển hướng sang 1 trang bảo trì, vì vậy, mình sẽ sử dụng nhóm 3xx để thông báo lỗi này, VD: 314 - Under Maintenance Handle lỗi với messageĐi cùng với việc trả về status để phía client biết được nó có bị lỗi hay không, thì thường thì mọi người sẽ trả cùng nó 1 cái message đi cùng với message default của status, VD: lúc client thực hiện gọi 1 API để thông tin sinh viên bằng MSSV, nếu server không tìm thấy sinh viên đó thì có thể thông báo
Ở các nhóm lỗi, điều cần nhớ là cần có sự consistency nhất định giữa chúng, VD
1 thì với mã lỗi
2 hoặc
3 cũng nên là
4 và
5. Như vậy, đối với backend, mình sẽ có 1 cái mapping từ lỗi sang status, ở frontend thì ngươcj lại, sẽ mapping từ status sang lỗi. Vì ở trên, mình đã định nghĩa danh sách lỗi consistency rồi, nên ở dưới này, việc chuyển từ status -> Message sẽ đơn giản hơn, thay vì define rõ ra 100, 101, 102, 103... thằng nào message gì, hay
6 có status bao nhiêu,
7 có status bao nhiêu 1 cách rõ ràng, thì nó sẽ làm cho code bị duplicate khá nhiều (vi phạm nguyên tắc DRY - Don't Repeat Yourself). EndTóm lại, thay vì trả về status cùng 1 cái message rõ nghĩa, chúng ta nên trả về 1 status, 1 mã lỗi đi kèm với những giá trị mô tả lỗi. Còn cách hiện thị lỗi như thế nào, việc đó hãy để cho Frontend quyết định, như vậy, lúc mà design thay đổi, thì chỉ cần vào frontend sửa code là xong, mà không cần phải sửa cả Frontend lẫn backend. ExampleSau đây, mình sẽ demo hàm get message ở Frontend và hàm get status ở backend (viết bằng JS)
Với backend, ở
8 thay vì map từ status qua content thì mình map từ 1 content qua message.
Kết bàiPhần này thì mình cũng méo biết nói gì, ngoài việc hy vọng mn đọc xong bài này, sẽ hiểu rõ và sử dụng đúng cách các mã trạng thái của HTTP. |