2013-02-12 28 views
17

Cách thích hợp để đưa ra ước tính cho yêu cầu hoàn thành khi máy chủ trả về mã trạng thái 202 - Accepted cho các yêu cầu không đồng bộ là gì?Trạng thái HTTP 202 - cách cung cấp thông tin về hoàn thành yêu cầu không đồng bộ?

Từ HTTP spec (nghiêng thêm bởi tôi):

202 Accepted

Yêu cầu đã được chấp nhận để xử lý, nhưng việc xử lý chưa được hoàn thành. [...]

Thực thể trả về với phản hồi này NÊN bao gồm chỉ báo trạng thái hiện tại của yêu cầu và một con trỏ đến màn hình trạng thái hoặc ước tính thời điểm người dùng có thể yêu cầu được hoàn thành.

Dưới đây là một số suy nghĩ:

  • tôi đã liếc nhìn chỉ thị max-age, nhưng sử dụng nó sẽ được lạm dụng Cache-Control?
  • Trả về thời gian chờ đợi dự kiến ​​trong nội dung phản hồi?
  • Thêm một ứng dụng cụ thể X- tiêu đề phản hồi, nhưng tiêu đề X- không được chấp nhận trong RFC 6648?
  • Thêm (không X-) tiêu đề phản hồi cụ thể? Nếu vậy, nó nên được đặt tên như thế nào? Câu hỏi SO Custom HTTP headers : naming conventions đã đưa ra một số ý tưởng, nhưng sau khi ngừng sử dụng nó chỉ trả lời các tiêu đề HTTP được định dạng như thế nào, không phải cách chúng được đặt tên.
  • Các đề xuất khác?

Trả lời

5

Mặc dù không được đề cập cụ thể cho mã phản hồi 202 - Accepted, tiêu đề Retry-After có vẻ là một tùy chọn phù hợp. Từ số documentation:

Trường tiêu đề phản hồi lại có thể được sử dụng [...] để cho biết dịch vụ dự kiến ​​sẽ không khả dụng đối với khách hàng yêu cầu trong bao lâu.

+1

Cho rằng giá trị được cho là "số nguyên giây (trong thập phân) ", nếu chúng ta muốn có độ phân giải tốt hơn, sẽ là tiêu đề' X-Retry-After' với các giá trị trong ví dụ mili giây thích hợp hơn thay thế? –

+0

@JosipRodin Tôi khuyên bạn nên sử dụng 'Thử lại sau: 0' thay vì phát minh tiêu đề tùy chỉnh vì thời gian khách hàng nhận được phản hồi một vài phần nghìn giây đã trôi qua và họ có thể thử lại ngay lập tức. Trong trường hợp hoạt động không đồng bộ, 'Retry-After: 0' dường như nói" kết quả chưa sẵn sàng, nhưng vui lòng hỏi lại (bất cứ khi nào bạn muốn). " – Gili

+0

@Gili nhưng nếu tôi không muốn họ hỏi bất cứ khi nào họ muốn thì sao? Ví dụ: nếu số lượng lớn ứng dụng khách cách 150ms, đó là 6 yêu cầu mỗi giây, nơi tôi có thể có ý tưởng chỉ có 2 yêu cầu mỗi giây. –

8

Chắc chắn không lạm dụng tiêu đề HTTP hiện tại cho việc này. Vì đó là máy chủ của riêng bạn, bạn sẽ xác định xem phản hồi sẽ như thế nào. Bạn có thể (và nên) chọn bất kỳ phản hồi nào phù hợp nhất với người nhận thông tin này và trả lại thông tin thực tế trong nội dung phản hồi.

Ví dụ: nếu bạn chỉ muốn hiển thị thông báo có thể đọc được, bạn có thể trả lại text/plain cho biết "Yêu cầu của bạn có thể được xử lý trong 30 phút tiếp theo".

Ở đầu kia của quang phổ, bạn có thể muốn đi tất cả các cách REST và trở application/json, có lẽ được định dạng như thế này (tôi hoàn toàn làm này lên ngay tại chỗ):

{ 
    "status": "pending", 
    "completion": { 
    "estimate": "Thu Sep 08 2011 12:00:00 GMT-0400", 
    "rejected-after": "Fri Sep 09 2011 12:00:00 GMT-0400", 
    }, 
    "tracking": { 
    "url": "http://server/status?id=myUniqueId" 
    } 
} 
9

Bạn có thể sử dụng tiêu đề Location để chỉ định URL của trình theo dõi trạng thái. Những thứ như trạng thái hiện tại và ước tính có thể đi vào tiêu đề tùy chỉnh (mà không có phần mềm nào mà phần mềm của riêng bạn sẽ sử dụng) hoặc trong nội dung phản hồi (trình duyệt web sẽ hiển thị cho người dùng, ít nhất).

+0

Cảm ơn, tôi đã quên tiêu đề 'Vị trí'. Rất có thể, chúng tôi sẽ sử dụng một cơ thể phản hồi tùy chỉnh. – matsev

+0

Khi nó xảy ra, một thực tế không thể sử dụng tiêu đề 'Vị trí' với HTTP 202 trong PHP, bởi vì nó thực thi ngữ nghĩa đặc biệt cho mỗi RFC 2616, cf. http://php.net/manual/en/function.header.php "Trường hợp đặc biệt thứ hai là tiêu đề" Vị trí: ", không chỉ gửi tiêu đề này trở lại trình duyệt mà còn trả về REDIRECT (302)) mã trạng thái cho trình duyệt trừ khi mã trạng thái 201 hoặc mã 3xx đã được đặt. " –

+0

@JosipRodin RFC 2616 không hạn chế 'Vị trí' không được sử dụng trong 202 (hoặc bất kỳ phản hồi nào khác), nó chỉ xác định' Vị trí' đề cập đến trường hợp 201/3xx. Vì vậy, đó là một ngữ nghĩa PHP (hoặc lỗi, tùy thuộc vào cách bạn nhìn vào nó), không phải là một ngữ nghĩa HTTP. –

Các vấn đề liên quan