HTTP 202 được chấp nhận (HTTP / 1.1)
Bạn đang tìm kiếm HTTP 202 Acceptedtrạng thái. Xem RFC 2616 :
Yêu cầu đã được chấp nhận để xử lý, nhưng việc xử lý chưa được hoàn thành.
Xử lý HTTP 102 (WebDAV)
RFC 2518 đề nghị sử dụng HTTP 102 Processing:
Mã trạng thái 102 (Đang xử lý) là một phản hồi tạm thời được sử dụng để thông báo cho khách hàng rằng máy chủ đã chấp nhận yêu cầu hoàn chỉnh, nhưng vẫn chưa hoàn thành.
nhưng nó có một cảnh báo:
Máy chủ PHẢI gửi phản hồi cuối cùng sau khi yêu cầu được hoàn thành.
Tôi không chắc làm thế nào để giải thích câu cuối cùng. Máy chủ có nên tránh gửi bất cứ điều gì trong quá trình xử lý và chỉ phản hồi sau khi hoàn thành? Hoặc nó chỉ buộc kết thúc phản hồi chỉ khi quá trình xử lý chấm dứt? Điều này có thể hữu ích nếu bạn muốn báo cáo tiến độ. Gửi HTTP 102 và tuôn ra byte phản hồi theo byte (hoặc từng dòng).
Chẳng hạn, đối với một quá trình dài nhưng tuyến tính, bạn có thể gửi một trăm dấu chấm, xả sau mỗi ký tự. Nếu phía máy khách (chẳng hạn như ứng dụng JavaScript) biết rằng nó sẽ mong đợi chính xác 100 ký tự, thì nó có thể khớp với thanh tiến trình để hiển thị cho người dùng.
Một ví dụ khác liên quan đến một quá trình bao gồm một số bước phi tuyến tính. Sau mỗi bước, bạn có thể xóa một thông điệp tường trình cuối cùng sẽ được hiển thị cho người dùng, để người dùng cuối có thể biết quá trình đang diễn ra như thế nào.
Các vấn đề với xả nước lũy tiến
Lưu ý rằng trong khi kỹ thuật này có giá trị của nó, tôi sẽ không đề xuất nó . Một trong những lý do là nó buộc kết nối vẫn mở, điều này có thể ảnh hưởng đến tính khả dụng của dịch vụ và không mở rộng tốt.
Cách tiếp cận tốt hơn là phản hồi HTTP 202 Acceptedvà cho phép người dùng quay lại với bạn sau để xác định xem việc xử lý đã kết thúc hay chưa (ví dụ bằng cách gọi liên tục một URI đã cho, như /process/resultsẽ phản hồi với HTTP 404 Không tìm thấy hoặc Xung đột HTTP 409 cho đến khi quá trình xử lý kết thúc và kết quả đã sẵn sàng) hoặc thông báo cho người dùng khi quá trình xử lý được thực hiện nếu bạn có thể gọi lại máy khách thông qua dịch vụ xếp hàng tin nhắn ( ví dụ ) hoặc WebSockets.
Ví dụ thực tế
Hãy tưởng tượng một dịch vụ web chuyển đổi video. Điểm vào là:
POST /video/convert
trong đó lấy một tệp video từ yêu cầu HTTP và thực hiện một số phép thuật với nó. Chúng ta hãy tưởng tượng rằng phép thuật này rất tốn CPU, vì vậy nó không thể được thực hiện trong thời gian thực trong quá trình chuyển yêu cầu. Điều này có nghĩa là một khi tệp được chuyển, máy chủ sẽ phản hồi với một HTTP 202 Acceptedsố nội dung JSON, nghĩa là có Có, tôi đã nhận được video của bạn và tôi đang làm việc với nó; nó sẽ sẵn sàng ở đâu đó trong tương lai và sẽ có sẵn thông qua ID 123.
Khách hàng có khả năng đăng ký hàng đợi tin nhắn để được thông báo khi quá trình xử lý kết thúc. Sau khi kết thúc, khách hàng có thể tải xuống video đã xử lý bằng cách truy cập:
GET /video/download/123
dẫn đến một HTTP 200.
Điều gì xảy ra nếu máy khách truy vấn URI này trước khi nhận được thông báo? Chà, máy chủ sẽ phản hồi HTTP 404vì, thực sự, video chưa tồn tại. Nó có thể được chuẩn bị hiện tại. Nó có thể không bao giờ được yêu cầu. Nó có thể tồn tại một thời gian trong quá khứ và được gỡ bỏ sau đó. Tất cả vấn đề là video kết quả không có sẵn.
Bây giờ, điều gì sẽ xảy ra nếu khách hàng quan tâm không chỉ về video cuối cùng mà còn về tiến trình (điều này thậm chí còn quan trọng hơn nếu không có dịch vụ xếp hàng tin nhắn hoặc bất kỳ cơ chế tương tự nào)?
Trong trường hợp này, bạn có thể sử dụng điểm cuối khác:
GET /video/status/123
mà sẽ dẫn đến một phản ứng tương tự như thế này:
HTTP 200
{
"id": 123,
"status": "queued",
"priority": 2,
"progress-percent": 0,
"submitted-utc-time": "2016-04-19T13:59:22"
}
Thực hiện yêu cầu nhiều lần sẽ cho thấy tiến trình cho đến khi:
HTTP 200
{
"id": 123,
"status": "done",
"progress-percent": 100,
"submitted-utc-time": "2016-04-19T13:59:22"
}
Điều rất quan trọng để tạo sự khác biệt giữa ba loại yêu cầu:
POST /video/convertxếp hàng một nhiệm vụ. Nó chỉ được gọi một lần: gọi lại sẽ xếp hàng một nhiệm vụ bổ sung.GET /video/download/123liên quan đến kết quả của hoạt động: tài nguyên là video. Việc xử lý điều đó là những gì đã xảy ra dưới mui xe để chuẩn bị kết quả thực tế trước khi yêu cầu và độc lập với yêu cầu, điều này không liên quan ở đây. Nó có thể được gọi một lần hoặc nhiều lần.GET /video/status/123liên quan đến việc xử lý mỗi se . Nó không xếp hàng gì cả. Nó không quan tâm đến video kết quả. Tài nguyên là chính nó xử lý. Nó có thể được gọi một lần hoặc nhiều lần.