PHP và tiêu đề HTTP tùy chỉnh, thực hành không tốt?

Question

Tôi có một triển khai tùy chỉnh một API RESTful cho một ứng dụng PHP trả về dữ liệu json và để truyền đạt trạng thái của hoạt động, tức là có lỗi trong yêu cầu, tôi đang đặt tiêu đề HTTP tùy chỉnh với một (rất nhỏ) đối tượng json như một chuỗi. Điều này hoạt động tốt vì tôi có thể gửi phản hồi và dễ dàng truy xuất chúng mà không gây rối với dữ liệu thực tế được gửi.

Câu hỏi đặt ra là, có bất kỳ hạn chế nào mà tôi có thể không nhận ra khi sử dụng phương pháp này không? Nó không có vẻ là rất phổ biến cho các ứng dụng để thiết lập tiêu đề tùy chỉnh http, vì vậy tôi tự hỏi cho dù đó là một thực hành xấu hoặc xấu "hương vị" bằng cách nào đó.

Answer 1

Đây là một câu hỏi thú vị. Không nên có bất kỳ lý do gì cho vấn đề, nhưng bạn nên tính đến một số điều sau:

1. Các tiêu đề cần phải là duy nhất cho ứng dụng của bạn. Không chỉ bây giờ, nhưng mãi mãi. Bạn nên đảm bảo bạn đang đặt tiền tố cho chúng, ví dụ: X-MyApplication-Foo: Bar. Không làm điều này có thể gây ra xung đột trong tương lai.
   
   
2. Tường lửa đôi khi (hiếm khi) hơi quá mức với lọc tiêu đề HTTP không xác định. Đây không phải là vấn đề, nhưng đó là điều cần ghi nhớ.
   
   
3. Trình duyệt cũ hơn có giới hạn nhỏ hơn về kích thước trường tiêu đề so với trình duyệt hiện đại, vì vậy bạn cần kiểm tra bao nhiêu lần bạn có thể nắm giữ.
   
   

Có lý do nào bạn không thể sử dụng mã lỗi HTTP chuẩn không? Tôi hiểu rằng bạn có thể muốn cung cấp dấu vết ngăn xếp hoặc thông tin gỡ lỗi hữu ích khác, nhưng trong trường hợp có lỗi, bạn sẽ không chỉ trả về một blob JSON có chứa thông tin lỗi, thay vì dữ liệu JSON "kết quả" bình thường? Bạn có thể dễ dàng phát hiện sự khác biệt dựa trên mã lỗi HTTP và xử lý hai trường hợp khác nhau.

Lý do tôi quan tâm theo cách tiếp cận được đề xuất của bạn là tiêu đề được sử dụng để thay đổi hoặc làm cho trình duyệt hành vi - chúng không phải là cơ chế lưu trữ dữ liệu.

Pseudo-code ví dụ:

switch(httpResponseCode) 
{ 
    case 200: 
     parseResult(json); 
     break; 
    case 403: 
     parseForbidden(json); 
     break; 
    case 500: 
     parseServerError(json); 
     break; 
    default: 
     // bad response code, handle appropriately 
}