Các đối tượng Yêu cầu / Phản hồi HTTP có nên bất biến không?

Tôi nghĩ thật an toàn khi nói rằng hầu hết các ứng dụng web đều dựa trên mô hình yêu cầu / phản hồi. PHP chưa bao giờ có một sự trừu tượng hóa chính thức của các đối tượng này. Một nhóm đang cố gắng thay đổi điều này: https://github.com/php-fig/fig-stiterias/blob/master/proposed/http-message.md

Tuy nhiên, họ đã có mặt theo dõi về vấn đề bất biến. Một mặt, đối tượng yêu cầu / phản hồi thường cần rất ít thay đổi trong vòng đời của chúng. Mặt khác, đối tượng phản hồi nói riêng thường cần thêm các tiêu đề HTTP.

Hơn nữa, tính bất biến chưa bao giờ thực sự bị cuốn vào vùng đất của PHP.

Những lợi thế nào mọi người nhìn thấy trong việc sử dụng các đối tượng yêu cầu / phản hồi bất biến?

Giả sử bạn đang trả lại một đối tượng json.

$response = new JsonResponse($item);

Đẹp và đơn giản. Nhưng hóa ra yêu cầu đó là yêu cầu Chia sẻ tài nguyên nguồn gốc (CORS). Mã tạo ra phản hồi không nên quan tâm nhưng ở đâu đó phía dưới là một quá trình sẽ thêm các tiêu đề Kiểm soát truy cập cần thiết. Bất kỳ lợi thế nào để giữ phản hồi ban đầu và tạo một phản hồi mới với các tiêu đề bổ sung? Hoặc nó là một câu hỏi về phong cách lập trình.

Đối tượng yêu cầu thú vị hơn một chút. Nó bắt đầu như nhau:

$request = new Request('incoming request information including uri and headers');

Các thông tin ban đầu không cần phải thay đổi. Tuy nhiên, vì yêu cầu được chuyển qua, thường cần thêm thông tin xử lý bổ sung. Ví dụ: bạn có thể có một công cụ đối sánh url quyết định hành động nào sẽ được thực hiện cho một yêu cầu đã cho.

$request->setAttribute('action',function() {});

Thực tế thực hiện hành động là trách nhiệm của một quá trình dòng xuống. Bạn có thể có một RequestAttributCollection có thể thay đổi, nó bao bọc yêu cầu bất biến nhưng điều đó có xu hướng hơi khó xử trong thực tế. Bạn cũng có thể có một yêu cầu không thay đổi ngoại trừ bộ sưu tập thuộc tính. Ngoại lệ cũng có xu hướng khó xử. Bất kỳ kinh nghiệm về việc đối phó với các loại yêu cầu?

Những lợi thế nào mọi người nhìn thấy trong việc sử dụng các đối tượng yêu cầu / phản hồi bất biến?

Tôi đồng ý với tuyên bố của @ MainMa " Tôi không chắc rằng lợi ích nhỏ của khả năng đọc có thể bù đắp cho sự thiếu linh hoạt có thể không " và cá nhân tôi không thấy bất kỳ khía cạnh thực tế và hữu ích nào khi buộc PHP HTTP Requestcác đối tượng PHP HTTP Responsetạm thời hoặc các đối tượng tạm thời là bất biến

Bất kỳ kinh nghiệm về việc đối phó với các loại yêu cầu?

1. Windows Presentation FoundationKhung của Microsoft giới thiệu khái niệm về các đối tượng có thể đóng băng . Khi bị đóng băng, các vật thể đó trở thành

   • không thay đổi (ném ngoại lệ khi cố gắng sửa đổi),
   • sử dụng nhanh hơn (người sử dụng tài sản không cần phải thực hiện bất kỳ quyết định "giá trị nào của tôi"?
   • tiêu thụ ít bộ nhớ hơn (cấu trúc dữ liệu của bộ trợ giúp nội bộ và bộ nhớ cache, v.v. có thể được giảm xuống thành biểu diễn hiệu quả nhất về không gian và thời gian của họ)
   • và có thể chia sẻ

   Mặc dù nó được sử dụng làm tối ưu hóa tốc độ GUI, nhưng bản thân khái niệm này cũng được áp dụng ở những nơi khác, bao gồm cả lợi ích của nó

2. Nancy("Nhẹ, lễ thấp, khung để xây dựng các dịch vụ dựa trên HTTP trên .Net và Mono") mô tả lợi ích của tính bất biến trong một trong các nhận xét cam kết như

   ... Chúng tôi có thể cho rằng bộ nhớ cache của chúng tôi là bất biến nếu chúng tắt, điều đó có nghĩa là chúng tôi không có khóa để hiệu suất nhanh hơn (mặc dù lượt truy cập không lớn) ...

   Tôi không tìm thấy bất kỳ ý kiến đáng chú ý khác về tính bất biến, nhưng lợi ích của tái sử dụng, đối tượng đáp ứng khả năng lưu nhớ có thể áp dụng để PHPcũng

Ở trên có thể giống như câu trả lời ngoài chủ đề, nhưng tôi không biết gì khác và đó là lý do tại sao tôi nghĩ rằng yêu cầu bất biến là một vấn đề nhân tạo và thay vì vấn đề ưu tiên hoặc phong cách mã hóa, v.v.

Đối tượng bất biến nói chung có một số lợi ích.

• Điều quan trọng nhất là việc sử dụng các đối tượng bất biến trong mã được thực thi song song dễ dàng như thế nào. Điều này cũng giải thích tại sao "tính bất biến chưa bao giờ thực sự bị cuốn vào vùng đất của PHP" .

• Thống nhất nhà nước là dễ dàng để có được.

• Đối tượng là dễ dàng, tự nhiên hơn để làm việc với.

Điều cốt yếu là đối tượng sẽ thay đổi bao nhiêu trong suốt thời gian tồn tại của mình. Mỗi thay đổi đối với một đối tượng bất biến đòi hỏi phải tạo ra một thể hiện bổ sung, có thể nhanh chóng quá tốn kém về bộ nhớ (và có thể cả chu kỳ CPU). Đây cũng là lý do tại sao hầu hết các ngôn ngữ lập trình stringkhông thể kết thúc lại có một lớp khác cho một số chuỗi có thể thay đổi, chẳng hạn như StringBuildertrong C #, để đáp ứng với các tình huống trong đó các chuỗi được nối từ nhiều phần nhỏ, mỗi phần được thêm động.

Trong thư viện phía máy khách (gửi yêu cầu HTTP và nhận phản hồi), sẽ rất hợp lý khi thực hiện yêu cầu và phản hồi HTTP: trong khi một số yêu cầu có thể được xây dựng với giao diện trôi chảy, đây không phải là cách sử dụng chính. Câu trả lời sẽ không được thay đổi, vì vậy tính bất biến có ý nghĩa.

Trong thư viện phía máy chủ (nhận yêu cầu HTTP và gửi phản hồi), trong khi yêu cầu có thể không thay đổi, tôi không chắc liệu phản hồi có thể được không. Bản thân dữ liệu có thể là một luồng (mà đối với một số người, giáo sư nhìn thấy bên dưới, buộc đối tượng phản hồi có thể thay đổi được) và bản thân các tiêu đề có thể được thêm "nhanh chóng" trong khi thực thi tập lệnh, cho đến khi phản hồi bắt đầu được gửi cho khách hàng.

Trong cả hai trường hợp, do không có sự thực thi song song, tôi không chắc liệu lợi ích nhỏ của khả năng đọc có bù đắp cho sự thiếu linh hoạt có thể xảy ra hay không.

Hãy chắc chắn rằng bạn cũng đã đọc một bài viết đầy đủ hơn của Evert Pot về PSR-7 . Bài báo giải thích, trong số những người khác, hơn một trong những trường hợp mà tính bất biến như vậy là có vấn đề là cho các phản hồi dài cần được truyền phát . Cá nhân, tôi không thấy vấn đề: IMHO, không có gì cấm một đối tượng bất biến chứa luồng (ví dụ, một FileReaderđối tượng có thể là bất biến ngay cả khi nó đọc một tệp có thể thay đổi theo thời gian). Khung Flask của Python sử dụng một cách tiếp cận khác khi nói đến các phản hồi lớn (hoặc các phản hồi cần có thời gian để tạo) bằng cách trả về một trình vòng lặp.