HTTP İstek / Yanıt nesneleri değiştirilemez mi?

Çoğu web uygulamasının istek / yanıt paradigmasına dayandığını söylemek güvenli olduğunu düşünüyorum. PHP hiçbir zaman bu nesnelerin resmi bir soyutlamasına sahip olmamıştır. Bir grup bunu değiştirmeye çalışıyor: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md

Ancak, değişmezlik konusunda bir bakıma yan izler aldı. Bir yandan, istek / yanıt nesnesinin yaşam döngüleri boyunca genellikle çok az değişikliğe ihtiyacı vardır. Öte yandan, yanıt nesnesinin özellikle HTTP üstbilgilerinin eklenmesi gerekir.

Dahası, PHP ülkesinde değişmezlik asla gerçekten yakalanmadı.

İnsanlar değişmez istek / yanıt nesnelerini kullanırken ne gibi avantajlar görüyor?

Bir json nesnesi döndürdüğünüzü varsayalım.

$response = new JsonResponse($item);

Güzel ve basit. Ancak, isteğin bir Kaynaklar Arası Kaynak Paylaşımı (CORS) isteği olduğu ortaya çıktı. Yanıtı üreten kod umursamaz ancak akış aşağısında gerekli Erişim-Denetim başlıklarını ekleyen bir işlemdir. Orijinal yanıtı tutmanın ve ek başlıklarla yeni bir yanıt oluşturmanın herhangi bir avantajı var mı? Yoksa kesinlikle bir programlama tarzı meselesi.

İstek nesnesi biraz daha ilginç. Aynı başlar:

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

İlk bilgilerin değiştirilmesi gerekmez. Bununla birlikte, istek iletilirken, genellikle ek işleme bilgileri ekleme ihtiyacı vardır. Örneğin, belirli bir istek için hangi işlemin gerçekleştirilmesi gerektiğine karar veren bir URL eşleştiriciniz olabilir.

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

Aslında eylemin yürütülmesi, aşağı akış sürecinin sorumluluğundadır. Değişmez isteği saran ancak pratikte biraz garip olma eğiliminde olan değiştirilebilir bir RequestAttributesCollection'a sahip olabilirsiniz. Öznitelik koleksiyonu dışında değiştirilemeyen bir isteğiniz de olabilir. İstisnalar da garip olma eğilimindedir. Bu tür gereksinimlerle başa çıkmak konusunda deneyiminiz var mı?

İnsanlar değişmez istek / yanıt nesnelerini kullanırken ne gibi avantajlar görüyor?

@ MainMa'nın " okunabilirliğin hafif faydasının olası esneklik eksikliğini telafi edip etmediğinden emin değilim " ifadesine katılıyorum ve şahsen PHP HTTP Requestgeçici nesneleri veya PHP HTTP Responsegeçici nesneleri değişmez olmaya zorlamanın pratik ve kullanışlı yönlerini görmüyorum

Bu tür gereksinimlerle başa çıkmak konusunda deneyiminiz var mı?

1. Microsoft'un Windows Presentation Foundationçerçevesi, donabilir nesneler konseptini sunar . Donduğunda, bu tür nesneler

   • değişmez (değişiklik denendiğinde istisnalar atın),
   • daha hızlı kullanmak (mülk sahiplerinin artık "değerim nedir?" kararlarını herhangi bir fantezi yapmasına gerek yok),
   • daha az bellek tüketmek (dahili yardımcı veri yapıları ve önbellekleri vb.
   • ve paylaşılabilir

   GUI hız optimizasyonu olarak kullanılmasına rağmen, kavramın kendisi, avantajları da dahil olmak üzere başka yerlerde de uygulanabilir.

2. Nancy("Net, Mono'da HTTP tabanlı hizmetler oluşturmak için hafif, düşük törenli çerçeve") , taahhüt yorumlarından birinde değişmezliğin faydasını şu şekilde açıklamaktadır :

   ... önbelleklerimizin kapalıysa değişmez olduğunu varsayabiliriz, yani kilitler çok daha hızlı performansımız olmaz (vuruş çok büyük olmasa da) ...

   Ben değişmezliği hakkında başka kayda değer bir yorum bulamadık ama yeniden ön belleğe tepki nesnelerin yararı için geçerli olabilir PHPde

Yukarıdakiler konu dışı cevaplara benzeyebilir, ancak başka hiçbir şeyin farkında değilim ve bu yüzden değişmezlik gereksiniminin yapay bir sorun olduğunu ve tercih veya kodlama tarzı vb.

Değişmez nesnelerin genel olarak çeşitli faydaları vardır.

• Bunlardan en önemlisi, paralel olarak çalıştırılan kodda değişmez nesneleri kullanmak ne kadar kolay. Bu aynı zamanda "değişmezliğin PHP ülkesinde neden hiç yakalanmadığını" açıklıyor .

• Devlet tutarlılığı elde etmek daha kolaydır.

• Nesneler kolay, çalışmak daha doğal.

Önemli olan, nesnenin yaşam süresi boyunca ne kadar değişmesi gerektiğidir - değişmez bir nesnede yapılan her değişiklik, bellek açısından (ve muhtemelen CPU döngülerinde) çok pahalı olabilecek ek bir örnek oluşturmayı gerektirir. Bu nedenle string, değişmez olan çoğu programlama dili StringBuilder, her parça dinamik olarak eklenen dizelerin birçok küçük parçadan birleştirildiği durumlara yanıt vermek için C # gibi bir çeşit değiştirilebilir dizeler için başka bir sınıfa sahip olur .

İstemci tarafı kitaplığında (HTTP isteği gönderme ve yanıt alma), HTTP isteğini ve yanıtı değiştirilemez hale getirmek mantıklıdır: bazı istekler akıcı bir arabirimle oluşturulabilirken, bu en önemli kullanım değildir. Yanıt yine de değişmeyecek, bu yüzden değişmezlik mantıklı.

Bir sunucu tarafı kitaplığında (HTTP isteği alma ve yanıt gönderme), istek değiştirilemezken, yanıtın olup olmadığından emin değilim. Verilerin kendisi bir akış olabilir (bazı insanlar için - aşağıya bakın - yanıt nesnesini değiştirilebilir olmaya zorlar) ve başlıklar, yanıt başlamadan önce komut dosyasının yürütülmesi sırasında "anında" eklenebilir müşteriye gönderilir.

Her iki durumda da, paralel bir yürütme olmadığı göz önüne alındığında, okunabilirliğin hafif faydasının olası esneklik eksikliğini telafi edip etmediğinden emin değilim.

PSR-7 hakkında Evert Pot'un daha eksiksiz bir makalesini de okuduğunuzdan emin olun . Makale, diğerlerinin yanı sıra, bu tür bir değişmezliğin sorunlu olduğu durumlardan birinden, akması gereken uzun yanıtlar için olduğunu açıklamaktadır . Şahsen, şu noktayı görmüyorum: IMHO, hiçbir şey değişmez bir nesnenin bir akış içermesini yasaklamaz (örneğin, bir FileReadernesne zaman içinde değişebilen bir dosyayı okuyor olsa bile değişmez olabilir). Python'un Flask çerçevesi, bir yineleyici döndürerek büyük yanıtlar (veya üretilmesi zaman alan yanıtlar) söz konusu olduğunda farklı bir yaklaşım kullanır .