La chiave della domanda sull'uso di GET è se la semantica dell'operazione è sicura :
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm.
In breve: se utilizzi GET, comunichi ai clienti e ai componenti dell'intermediario che possono richiedere la risorsa ogni volta che lo desiderano, anche se il consumatore finale non l'ha richiesto.
Per definizione, i metodi sicuri sono necessariamente anche idempotenti
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request
Ad esempio, se il client invia una richiesta GET e non ottiene una risposta , si aspettano di essere in grado di inviare nuovamente la richiesta e ripeterla tutte le volte necessarie fino a quando arriva una risposta.
Se tali semantica non sono accettabili, probabilmente non dovresti utilizzare GET.
L'RFC 7231 offre un esempio di caso in cui la semantica "sicura" è appropriata anche se ci sono significativi effetti collaterali durante la gestione della richiesta
a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.
Dalla tua descrizione, mi sembra che questo potrebbe essere un caso in cui GET è una scelta accettabile.
Agree with the idempotent analysis, but prefer PUT
Certamente "registrami se non registrato" è un'azione idempotente. Non mi è chiaro dalla descrizione se questa è una parte prevista del protocollo, o se è davvero un dettaglio di implementazione.
Ma la semantica di PUT non è solo "idempotente"; in particolare, implicano che il cliente capisca una rappresentazione appropriata della risorsa. Non è chiaro dalla descrizione originale se ci si aspetta che il cliente abbia familiarità con i dettagli della registrazione, o se si tratta di un dettaglio di implementazione del client.
Inoltre, il tipo di media più comune per le rappresentazioni ipermediali è ancora HTML e i moduli HTML don ' t supporto PUT . Pertanto, devi aumentare la tua rappresentazione con codice su richiesta , oppure è necessario sostituire le rappresentazioni con un altro tipo di supporto che supporti le azioni PUT.
Naturalmente, molte API scartano il vincolo ipermediale ; che rende il metodo PUT più appetibile.
Frontend should not bother about any registration things, it just says us: "okay, I'm here, do whatever you need to get ready to work". Does this mean we should use GET then?
Sospetto che sia così: la tua descrizione mi ricorda un sacco di cache di read-through; con il cliente che chiede "dammi la rappresentazione attuale" e il server che si preoccupa dei dettagli (abbiamo una rappresentazione corrente? dobbiamo riconvalidarlo?). Gran parte della potenza di REST deriva dalla sua semantica del caching.
Potrebbe essere utile rivedere questa osservazione da Roy Fielding nel 2002
HTTP does not attempt to require the results of a GET to be safe.
What it does is require that the semantics of the operation be safe,
and therefore it is a fault of the implementation, not the interface
or the user of that interface, if anything happens as a result that
causes loss of property (money, BTW, is considered property for the
sake of this definition).