Чи повинні об’єкти запиту / відповіді HTTP бути незмінними?

Я думаю, що можна сказати, що більшість веб-додатків базуються на парадигмі запит / відповідь. У PHP ніколи не було формальної абстракції цих об'єктів. Одна група намагається змінити це: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md

Однак вони як би відстежували питання незмінності. З одного боку, об'єкт запиту / відповіді, як правило, потребує дуже незначних змін протягом свого життєвого циклу. З іншого боку, зокрема, об'єкт відповіді часто потребує додавання заголовків HTTP.

Крім того, незмінність ніколи насправді не натрапляла на землі PHP.

Які переваги бачать люди у використанні незмінних об'єктів запиту / відповіді?

Припустимо, ви повертаєте об’єкт json.

$response = new JsonResponse($item);

Приємно і просто. Але виявляється, що запит був запитом "Cross-Origin Resource Sharing" (CORS). Код, що генерує відповідь, не повинен хвилюватись, але десь внизу - це процес, який додасть необхідні заголовки Access-Control. Якась перевага зберегти оригінальну відповідь та створити нову з додатковими заголовками? Або це строго питання стилю програмування.

Об'єкт запиту трохи цікавіше. Це починається так само:

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

Початкову інформацію не потрібно змінювати. Однак, оскільки передається запит, часто виникає необхідність додати додаткову інформацію про обробку. Наприклад, у вас може бути відповідність URL-адреси, яка визначає, яку дію слід виконати для заданого запиту.

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

Фактично виконання дії є обов'язком процесу низхідного потоку. У вас може виникнути змінна RequestAttributesCollection, яка завершує непорушний запит, але це, як правило, трохи незручно. Ви також можете мати запит, незмінний за винятком колекції атрибутів. Винятки також є незручними. Якийсь досвід роботи з такими вимогами?

Які переваги бачать люди у використанні незмінних об'єктів запиту / відповіді?

Я погоджуюся з твердженням @ MainMa: " Я не впевнений, чи незначна користь читабельності компенсує можливу відсутність гнучкості ", і особисто я не бачу жодних практичних та корисних аспектів змушення PHP HTTP Requestтимчасових об'єктів чи PHP HTTP Responseтимчасових об'єктів бути незмінними

Якийсь досвід роботи з такими вимогами?

1. У Windows Presentation Foundationрамках Microsoft представлена ​​концепція об'єктів, що завіряються . Після застигання такі об'єкти стають

   • незмінний (викидати винятки при спробі модифікації),
   • швидше використовувати (особам, які отримують власність, більше не потрібно робити фантазійні рішення "яка моя ціна?"),
   • витрачається менше пам’яті (внутрішні допоміжні структури даних і кеші тощо, можна зменшити до ефективного представлення їх часу та простору)
   • і спільний доступ

   Хоча вона використовується як оптимізація швидкості GUI, сама концепція застосовна і в інших місцях, включаючи її переваги

2. Nancy("Легка, низька церемонія, структура для побудови HTTP-сервісів на .Net і Mono") описує перевагу незмінності в одному з коментарів комітету як

   ... ми можемо вважати, що наші кеші незмінні, якщо вони вимкнені, це означає, що у нас немає блокувань, настільки швидка продуктивність (хоча хіт не масова) ...

   Я не знайшов якісь - або інші примітні коментарі про незмінність, але користь від багаторазового використання, Кешована об'єктів реагування може застосовуватися до PHPа

Сказане може виглядати як поза тематичні відповіді, але я нічого не усвідомлюю, і тому я вважаю, що вимога незмінності є штучною проблемою, а скоріше питанням уподобань чи стилю кодування тощо.

Незмінні об'єкти в цілому мають ряд переваг.

• Найважливішим є те, наскільки просто використовувати незмінні об’єкти в коді, виконаному паралельно. Це також пояснює, чому "незмінність ніколи насправді не натрапила на землю PHP" .

• Державну послідовність отримати простіше.

• Об'єкти легко, природніше працювати.

Важливим є те, наскільки об'єкт повинен змінитися протягом свого життя - кожна зміна незмінного об'єкта вимагає створення додаткового екземпляра, який може бути занадто дорогим з точки зору пам'яті (і, мабуть, і процесорних циклів). Ось чому, більшість мов програмування, де stringнезмінне, в кінцевому підсумку має інший клас для якихось змінних рядків, наприклад, StringBuilderу C #, щоб реагувати на ситуації, коли рядки з'єднані з багатьох малих частин, кожна частина додається динамічно.

У бібліотеці на стороні клієнта (надсилання HTTP-запиту та отримання відповіді) має сенс зробити HTTP-запит та відповідь незмінними: хоча деякі запити можуть бути побудовані з вільним інтерфейсом, це не є основним використанням. Відповідь все одно не буде змінено, тому незмінність має сенс.

У бібліотеці на сервері (отримання HTTP-запиту та надсилання відповіді), хоча запит може бути незмінним, я не впевнений, чи може відповідь. Самі дані можуть бути потоком (який для деяких людей (див. Нижче) змушує об'єкт відповіді бути зміненим), а самі заголовки можуть бути додані "на льоту" під час виконання сценарію, поки відповідь не почне буде відправлено клієнту.

В обох випадках, враховуючи, що виконання не відбувається паралельно, я не впевнений, чи незначна користь читабельності компенсує можливу відсутність гнучкості.

Не забудьте також прочитати більш повну статтю Evert Pot про PSR-7 . У статті пояснюється, серед іншого, що один із випадків, коли така незмінність є проблематичною, - це тривалий відповідь, який слід передавати . Особисто я не бачу сенсу: IMHO, ніщо не забороняє незмінному об'єкту містити потік (наприклад, FileReaderоб’єкт може бути незмінним, навіть якщо він читає файл, який може змінюватися з часом). Флажок Python Flask використовує інший підхід, коли мова йде про великі відповіді (або відповіді, які потребують часу для генерування), повертаючи ітератор.