Ci sono problemi con l'implementazione di metodi HTTP personalizzati?

Abbiamo un URL nel seguente formato

/ Instance / {instanceType} / {} instanceId

Puoi chiamarlo con i metodi HTTP standard: POST, GET, DELETE, PUT. Tuttavia, ci sono alcune altre azioni che intraprendiamo come "Salva come bozza" o "Curare"

Pensavamo di poter usare solo metodi HTTP personalizzati come: DRAFT, VALIDATE, CURATE

Penso che questo sia accettabile poiché gli standard dicono

"Il set di metodi comuni per HTTP / 1.1 è definito di seguito. Sebbene questo set possa essere espanso, non si può presumere che metodi aggiuntivi condividano la stessa semantica per client e server estesi separatamente."

E strumenti come WebDav creano alcune delle proprie estensioni.

Ci sono problemi che qualcuno ha incontrato con metodi personalizzati? Sto pensando a server proxy e firewall, ma qualsiasi altra area di interesse è benvenuta. Dovrei rimanere al sicuro e avere solo un parametro URL come action = validate | curate | draft?

Uno dei vincoli fondamentali di HTTP e la caratteristica di progettazione centrale di REST è un'interfaccia uniforme fornita da (tra le altre cose) una piccola serie fissa di metodi che si applicano universalmente a tutte le risorse. Il vincolo di interfaccia uniforme ha una serie di aspetti positivi e negativi. Sto citando da Fielding qui liberamente.

Un'interfaccia uniforme:

• è più semplice.
• disaccoppia le implementazioni dai servizi che forniscono.
• consente un'architettura a più livelli, inclusi elementi come bilanciamento del carico HTTP (nginx) e cache (vernice).

D'altra parte, un'interfaccia uniforme:

• riduce l'efficienza, poiché le informazioni vengono trasferite in una forma standardizzata anziché in una specifica per le esigenze di un'applicazione.

I compromessi sono "progettati per il caso comune del Web" e hanno permesso di costruire un grande ecosistema che fornisce soluzioni a molti dei problemi comuni nelle architetture web. L'adesione a un'interfaccia uniforme consentirà al tuo sistema di beneficiare di questo ecosistema mentre la sua rottura lo renderà così difficile. È possibile che si desideri utilizzare un bilanciamento del carico come nginx, ma ora è possibile utilizzare solo un bilanciamento del carico che comprende DRAFT e CURATE. Potresti voler utilizzare un livello di cache HTTP come Varnish ma ora puoi utilizzare solo un livello di cache HTTP che comprende DRAFT e CURATE. Potresti chiedere a qualcuno aiuto per la risoluzione di un errore del server, ma nessun altro conosce la semantica di una richiesta CURATE. Potrebbe essere difficile modificare le librerie client o server preferite per comprendere e implementare correttamente i nuovi metodi. E così via.

Il modo corretto ^* di rappresentarlo è come una trasformazione di stato sulla risorsa (o risorse correlate). Non si disegna un post, si trasforma il suo draftstato trueo si crea una draftrisorsa che contiene le modifiche e i collegamenti alle precedenti versioni di bozza. Non CURATE un post, ne trasformate lo curatedstato trueo create una curationrisorsa che collega il post all'utente che lo ha curato.

^{* Corretto in quanto segue da vicino i principi dell'architettura REST.}

Preferirei progettare questi come risorse secondarie, su cui eseguire una richiesta POST.

Considerando che hai una risorsa in /instance/type/1, vorrei che la rappresentazione di quella risorsa trasmettesse un paio di collegamenti ad "azioni" che possono essere eseguite sulla risorsa, come /instance/type/1/drafte /instance/type/1/curate. In JSON, questo potrebbe essere semplice come:

{
    "some property":"the usual value",
    "state": "we can still inform the client about the current state",
    "draft": "http://server/instance/type/1/draft",
    "curate": "http://server/instance/type/1/curate"
}

Ciò consente al cliente di essere molto esplicito su ciò che deve accadere, durante la richiesta POST al collegamento fornito dal curatemembro. La risorsa pubblicata potrebbe includere argomenti che descrivono in dettaglio l'evento che potrebbe, forse, infliggere una transizione di stato.

Seguire l'approccio "ingenuo" di spostarsi tra i possibili stati su una risorsa ha lo svantaggio di non catturare quali eventi hanno portato a queste transizioni.

Le transizioni di stato di solito si verificano in risposta a eventi specifici e preferirei catturare quegli eventi piuttosto che lasciare che il client decida che qualcosa è ora in uno "stato" specifico. Inoltre rende la validazione molto più difficile. Inoltre, non saresti in grado di catturare alcun 'argomento' se non descrivi anche quelli nello stato stesso. E poi diventa tutto scemo quando un po 'di codice cambia quelli senza transizione di stato reale e la convalida richiesta, e tutto diventa rapidamente un casino.

Penso che il metodo HTTP personalizzato sia il modo migliore per implementare le azioni dell'entità. L'aggiunta dell'azione al corpo dell'entità (POST) non sembra corretta, non fa parte dell'entità (anche se il risultato potrebbe essere salvato in esso). Inoltre, l'utilizzo dei proxy HTTP personalizzati può determinare le loro azioni senza la necessità di analizzare il corpo dell'entità.

È come CRUD, vorresti sempre implementarli, ma hai anche il tuo specifico set di azioni (per enitity). Davvero non vedo quale sarebbe il problema estenderli.

Anche @Rein Henrichs "Non progetti un post, trasformi il suo stato di bozza in vero o crei una bozza di risorsa" mi sembra falso. Una draftsproprietà verrebbe utilizzata per il salvataggio persistente dello stato, non per la trasformazione. Le azioni non comportano necessariamente necessariamente uno "stato", né essere salvate in una proprietà. La creazione di un'entità separata per ogni stato / trasformazione sembra ancora più sfocata. Cerca di mantenere lo stesso riferimento (URI) all'entità.