Professionalità nell'implementazione del metodo HTTP "QUERY" in un'API

0

Alcuni anni fa, w3c ha documentato una proposta per un metodo chiamato QUERY, in cui le informazioni sulla query possono essere passate come corpo della richiesta piuttosto che sulla riga della richiesta nei parametri della query. Puoi vederlo qui: link

La mia domanda

Mi rendo conto che puoi inviare qualsiasi nome di verbo composto insieme alla tua richiesta HTTP, tuttavia mi piacerebbe sentire le tue opinioni sulla professionalità dell'adozione di un verbo come QUERY prima che quel metodo sia accettato come RFC. Se non off-topic, accetterò i precedenti e le risorse esemplari sull'implementazione di QUERY.

Un po 'più di sfondo su QUERY

Solo per chiarimenti, il mio interesse nel giustificare l'implementazione di QUERY ha 3 motivi principali.

1) Privacy Molti server HTTP, proxy e persino implementazioni di applicazioni hanno la tendenza a registrare l'intero URI come parte dei suoi registri di accesso di base. È del tutto possibile che un sistema possa aver bisogno di essere interrogato da determinati attributi che influiscono sulla conformità normativa, in particolare nei sistemi di pagamento o sanitari. Avere quei parametri di query visualizzati nei log di accesso potrebbe essere inaccettabile.

2) Dimensioni Inoltre, la proposta w3c non menziona il vincolo della dimensione della linea di richiesta da parte di molte implementazioni HTTP. Anche se non necessariamente specificato, ho riscontrato problemi con alcune applicazioni HTTP (client e server) che non gestivano una richiesta con una certa lunghezza lunga di quella linea di richiesta.

3) Complessità della query La complessità è già ben giustificata nella proposta w3c.

    
posta andyortlieb 10.08.2018 - 15:29
fonte

1 risposta

4

Che sia professionale o meno dipende da te e dalla politica della tua azienda. Tutto si riduce al rischio e al debito tecnico. Se dovessi comunicare con il tuo software come parte esterna, lo considererei una cattiva pratica, non necessariamente non professionale.

Direi che l'adozione di uno standard prima che sia accettato può essere rischioso. Che cosa farai se lo standard viene eliminato o quando i cambiamenti avvengono prima che sia accettato? Continuerai a lavorare con la tua versione dello standard, o tornerai indietro e cambierai tutto il tuo software?

Sei tu a controllare tutte le parti che devono comunicare usando questo standard? Se è così, allora si potrebbe dire che il rischio è minimo, dal momento che è possibile apportare le modifiche necessarie. Non appena avrai intenzione di comunicare o supportare parti esterne, o anche un altro sviluppatore, il rischio aumenta. Più fattori esterni entrano in gioco, maggiore sarà il tempo (debito tecnico) e il denaro necessario prima che il software venga aggiornato allo standard appropriato.

So che ci sono molti "se", ma questo è esattamente il problema quando si lavora con proposte sperimentali.

    
risposta data 10.08.2018 - 16:27
fonte

Leggi altre domande sui tag