Gli oggetti HTTP di richiesta / risposta dovrebbero essere immutabili?

Naviga le tue risposte
10

Penso sia sicuro affermare che la maggior parte delle applicazioni web si basano sul paradigma richiesta / risposta. PHP non ha mai avuto un'astrazione formale di questi oggetti. Un gruppo sta cercando di cambiare questo: link

Tuttavia, si sono in qualche modo distaccati sulla questione dell'immutabilità. Da un lato, l'oggetto richiesta / risposta generalmente ha bisogno di poche modifiche durante il loro ciclo di vita. D'altra parte, l'oggetto response in particolare spesso ha bisogno di intestazioni HTTP da aggiungere.

Inoltre, l'immutabilità non ha mai preso piede nella terra di PHP.

Quali vantaggi vedono le persone nell'usare oggetti immutabili di richiesta / risposta?

Supponiamo che tu stia restituendo un oggetto json. 

$response = new JsonResponse($item);

Bello e semplice. Ma si scopre che la richiesta era una richiesta CORS (Cross-Origin Resource Sharing). Il codice che genera la risposta non dovrebbe interessare ma da qualche parte a valle è un processo che aggiungerà le intestazioni necessarie per il controllo degli accessi. Qualunque vantaggio nel mantenere la risposta originale e crearne una nuova con le intestazioni aggiuntive? O è strettamente una questione di stile di programmazione.

L'oggetto richiesta è un po 'più interessante. Inizia lo stesso: 

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

Le informazioni iniziali non devono essere modificate. Tuttavia, man mano che la richiesta viene inoltrata, è spesso necessario aggiungere ulteriori informazioni di elaborazione. Ad esempio, potresti avere un url matcher che decide quale azione deve essere eseguita per una determinata richiesta. 

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

L'esecuzione effettiva dell'azione è responsabilità di un processo downstream. Potresti avere una RequestAttributesCollection mutabile che avvolge la richiesta immutabile, ma che in pratica tende ad essere un po 'scomoda. Potresti anche avere una richiesta immutabile, fatta eccezione per una raccolta di attributi. Anche le eccezioni tendono ad essere imbarazzanti. Qualche esperienza su come affrontare questo tipo di requisiti?

    
posta Cerad 05.04.2015 - 21:58
fonte

2 risposte

4

What advantages do people see in using immutable request/response objects?

Sono d'accordo con l'affermazione di @ MainMa " non sono sicuro se il leggero vantaggio della leggibilità compensa la possibile mancanza di flessibilità " e personalmente non vedo alcun aspetto pratico e utile del forzare PHP HTTP Request oggetti temporanei o PHP HTTP Response oggetti temporanei per essere immutabili

Any experience on dealing with these sorts of requirements?

  1. Il framework Windows Presentation Foundation di Microsoft introduce il concetto di oggetti freezable . Una volta congelati, tali oggetti diventano

    • immutabile (genera eccezioni quando si tenta la modifica),
    • più veloce da usare (i getter di proprietà non hanno più bisogno di prendere decisioni di fantasia "qual è il mio valore?",
    • consumare meno memoria (le strutture dati e le cache interne dell'helper possono essere ridotte alla loro rappresentazione più efficiente in termini di tempo e spazio)
    • e condivisibile

    Sebbene sia usato come ottimizzazione della velocità della GUI, il concetto stesso è applicabile anche altrove, inclusi i suoi benefici

  2. Nancy ("Leggero, bassa cerimonia, framework per la costruzione di servizi basati su HTTP su .Net e Mono") descrive il vantaggio dell'immutabilità in uno dei commenti di commit come

    ...we can assume our caches are immutable if they're off, which means we have no locks so faster performance (although the hit isn't massive)...

    Non ho trovato altri commenti degni di nota sull'immutabilità, ma il vantaggio degli oggetti di risposta riutilizzabili e memorizzabili nella cache potrebbe applicarsi anche a PHP

Quanto sopra può sembrare una risposta fuori tema, ma non sono a conoscenza di nient'altro ed è per questo che penso che il requisito dell'immutabilità sia un problema artificiale e piuttosto un problema di preferenza o di stile di codifica ecc.

    
risposta data 07.04.2015 - 15:34
fonte
7

Gli oggetti immutabili in generale hanno diversi vantaggi.

  • Il più importante è quanto sia facile utilizzare oggetti immutabili nel codice eseguito in parallelo. Questo spiega anche perché "l'immutabilità non ha mai preso piede nella terra di PHP" .

  • La coerenza dello stato è più facile da ottenere.

  • Gli oggetti sono facili, più naturali con cui lavorare.

La cosa essenziale è quanto l'oggetto dovrebbe cambiare durante il suo ciclo di vita: ogni modifica a un oggetto immutabile richiede la creazione di un'istanza aggiuntiva, che può essere rapidamente troppo costosa in termini di memoria (e probabilmente anche cicli CPU). Questo è anche il motivo per cui la maggior parte dei linguaggi di programmazione dove string è immutabile finisce per avere un'altra classe per una sorta di stringhe mutabili, come StringBuilder in C #, per rispondere alle situazioni in cui le stringhe sono concatenate da molte piccole parti, ogni parte aggiunta dinamicamente .

In una libreria lato client (inviando una richiesta HTTP e ricevendo una risposta), ha senso rendere immutabili la richiesta e la risposta HTTP: mentre alcune richieste potrebbero essere costruite con un'interfaccia fluente, questo non è l'uso principale. La risposta non verrà comunque modificata, quindi l'immutabilità ha senso.

In una libreria lato server (che riceve una richiesta HTTP e invia una risposta), mentre la richiesta può essere immutabile, non sono sicuro che la risposta possa essere. I dati stessi possono essere uno stream (che, per alcune persone - vedi sotto-costringe l'oggetto response a essere mutabile), e le intestazioni stesse possono essere aggiunte "al volo" durante l'esecuzione dello script, fino a quando la risposta inizia essere inviato al cliente.

In entrambi i casi, dato che non c'è esecuzione in parallelo, non sono sicuro che il leggero vantaggio della leggibilità compensi la possibile mancanza di flessibilità.

Assicurati di leggere anche un articolo più completo di Evert Pot su PSR-7 . L'articolo spiega, tra gli altri, di uno dei casi in cui tale immutabilità è problematica per lunghe risposte che dovrebbero essere trasmesse in streaming . Personalmente, non vedo il punto: IMHO, nulla impedisce ad un oggetto immutabile di contenere un flusso (per esempio, un oggetto FileReader può essere immutabile anche se legge un file che può cambiare nel tempo). Il framework Python's Flask utilizza un approccio diverso quando si tratta di risposte di grandi dimensioni (o di risposte che richiedono tempo per generare ) restituendo un iteratore.

    
risposta data 05.04.2015 - 23:01
fonte

Leggi altre domande sui tag

C'è qualche ragione per non usare Optional come argomento del metodo nel caso in cui tu sappia che l'argomento è qualcosa che può o non può essere necessario? best practice per inizializzare i membri della classe in php