Haruskah HTTP Request / Response object tidak berubah?

Saya pikir aman untuk mengatakan bahwa sebagian besar aplikasi web didasarkan pada paradigma permintaan / respons. PHP tidak pernah memiliki abstraksi formal dari objek-objek ini. Satu grup sedang mencoba untuk mengubah ini: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md

Namun, mereka semacam dilacak tentang masalah ketidakberdayaan. Di satu sisi, objek permintaan / respons umumnya membutuhkan sedikit perubahan selama siklus hidupnya. Di sisi lain, objek respons khususnya sering perlu header HTTP untuk ditambahkan.

Selain itu, ketidakberdayaan tidak pernah benar-benar tertangkap di tanah PHP.

Keuntungan apa yang dilihat orang dalam menggunakan objek permintaan / respons tidak berubah?

Misalkan Anda mengembalikan objek json.

$response = new JsonResponse($item);

Bagus dan sederhana. Tapi ternyata permintaan itu adalah permintaan Berbagi Sumber Daya Lintas Alam (CORS). Kode yang menghasilkan respons seharusnya tidak peduli tetapi di suatu tempat hilir adalah proses yang akan menambahkan header Access-Control yang diperlukan. Adakah manfaat untuk mempertahankan respons asli dan membuat yang baru dengan header tambahan? Atau apakah ini semata-mata masalah gaya pemrograman.

Objek permintaan sedikit lebih menarik. Mulai dari yang sama:

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

Informasi awal tidak perlu diubah. Namun, ketika permintaan diteruskan, seringkali ada kebutuhan untuk menambahkan informasi pemrosesan tambahan. Misalnya, Anda mungkin memiliki pencocokan url yang memutuskan tindakan apa yang harus dilakukan untuk permintaan yang diberikan.

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

Sebenarnya melaksanakan tindakan adalah tanggung jawab proses hilir. Anda bisa memiliki RequestAttributesCollection yang bisa berubah yang membungkus permintaan yang tidak dapat diubah tetapi itu cenderung agak canggung dalam praktiknya. Anda juga dapat memiliki permintaan yang tidak dapat diubah kecuali untuk koleksi atribut. Pengecualian cenderung canggung juga. Adakah pengalaman dalam berurusan dengan persyaratan semacam ini?

Keuntungan apa yang dilihat orang dalam menggunakan objek permintaan / respons tidak berubah?

Saya setuju dengan pernyataan @ MainMa " Saya tidak yakin apakah sedikit manfaat keterbacaan mengimbangi kemungkinan kurangnya fleksibilitas " dan secara pribadi saya tidak melihat aspek praktis dan berguna memaksa PHP HTTP Requestbenda- PHP HTTP Responsebenda sementara atau benda- benda sementara menjadi tidak berubah

Adakah pengalaman dalam berurusan dengan persyaratan semacam ini?

1. Windows Presentation FoundationKerangka kerja Microsoft memperkenalkan konsep objek yang dapat dibekukan . Setelah membeku, benda-benda tersebut menjadi

   • immutable (melempar pengecualian saat modifikasi dilakukan),
   • lebih cepat untuk digunakan (pengambil properti tidak perlu melakukan keputusan "berapa nilai saya?"),
   • memakan lebih sedikit memori (struktur data pembantu internal dan cache dll. dapat direduksi menjadi representasi paling efisien waktu & ruang)
   • dan dapat dibagikan

   Meskipun digunakan sebagai optimasi kecepatan GUI, konsep itu sendiri juga berlaku di tempat lain, termasuk manfaatnya

2. Nancy("Kerangka kerja ringan, upacara rendah, untuk membangun layanan berbasis HTTP di .Net dan Mono") menjelaskan manfaat ketetapan dalam salah satu komentar komit sebagai

   ... kita dapat menganggap cache kita tidak dapat diubah jika tidak aktif, yang berarti kita tidak memiliki kunci sehingga kinerjanya lebih cepat (walaupun hit tidak masif) ...

   Saya tidak menemukan komentar lain yang patut dicatat tentang kekekalan, tetapi manfaat dapat digunakan kembali, benda-benda respon disimpan di cache mungkin berlaku untuk PHPjuga

Jawaban di atas mungkin terlihat seperti jawaban di luar topik, tetapi saya tidak mengetahui hal lain dan itulah mengapa saya pikir persyaratan ketidakmampuan adalah masalah buatan dan lebih merupakan masalah preferensi atau gaya pengkodean dll.

Objek yang tidak dapat berubah secara umum memiliki beberapa manfaat.

• Yang paling penting adalah betapa mudahnya menggunakan objek yang tidak dapat diubah dalam kode yang dieksekusi secara paralel. Ini juga menjelaskan mengapa "ketetapan tidak pernah benar-benar tertangkap di tanah PHP" .

• Konsistensi negara lebih mudah diperoleh.

• Objek mudah, lebih alami untuk dikerjakan.

Yang penting adalah berapa banyak objek harus berubah selama masa hidupnya — setiap perubahan pada objek yang tidak dapat diubah harus membuat instance tambahan, yang dengan cepat bisa terlalu mahal dalam hal memori (dan mungkin juga siklus CPU). Ini juga mengapa sebagian besar bahasa pemrograman di mana stringtidak berubah akhirnya memiliki kelas lain untuk beberapa jenis string yang bisa berubah, seperti StringBuilderdalam C #, untuk menanggapi situasi di mana string digabungkan dari banyak bagian kecil, setiap bagian ditambahkan secara dinamis.

Di perpustakaan sisi klien (mengirim permintaan HTTP dan menerima respons), masuk akal untuk membuat permintaan dan respons HTTP tidak berubah: sementara beberapa permintaan dapat dibuat dengan antarmuka yang lancar, ini bukan penggunaan utama. Responsnya tidak akan berubah, jadi ketidakberdayaan masuk akal.

Di perpustakaan sisi server (menerima permintaan HTTP dan mengirim respons), sementara permintaan tidak dapat diubah, saya tidak yakin apakah jawabannya bisa. Data itu sendiri dapat berupa aliran (yang, bagi sebagian orang — lihat di bawah ini — memaksa objek respons agar bisa berubah), dan header itu sendiri dapat ditambahkan "dengan cepat" selama eksekusi skrip, hingga respons mulai dikirim ke klien.

Dalam kedua kasus, mengingat bahwa tidak ada eksekusi secara paralel, saya tidak yakin apakah sedikit manfaat keterbacaan mengkompensasi kemungkinan kurangnya fleksibilitas.

Pastikan Anda juga membaca artikel yang lebih lengkap dari Evert Pot tentang PSR-7 . Artikel tersebut menjelaskan, antara lain, dari salah satu kasus di mana ketidakberdayaan seperti itu bermasalah adalah untuk tanggapan lama yang harus dialirkan . Secara pribadi, saya tidak mengerti intinya: IMHO, tidak ada yang melarang objek yang tidak dapat diubah mengandung aliran (misalnya, FileReaderobjek dapat berubah bahkan jika ia membaca file yang dapat berubah dari waktu ke waktu). Kerangka kerja Flask Python menggunakan pendekatan yang berbeda ketika datang ke respon besar (atau tanggapan yang membutuhkan waktu untuk menghasilkan) dengan mengembalikan iterator.