Problemi di supporto del browser a parte, se sei un Http / hateoas stickler quali verbi dovrebbe essere la richiesta di accesso / uscita da un sito?
DELETE sembrerebbe la scelta più ovvia, ma non sono sicuro di quale sarebbe la risorsa che stai eliminando.
HTTP è senza stato, quindi non accedi / esci da un sito Web, sono solo nomi intelligenti che utilizziamo per l'implementazione dei cookie.
Quello che realmente fai è OTTENERE un token di autenticazione (cookie), dopo i dettagli di autenticazione POST. Che il tuo browser memorizzi quel cookie per te è solo una comodità. Infine, dopo aver terminato con il token di autenticazione, POST esegue il token sul server per informarlo che può essere distrutto. Di nuovo, tutto ciò accade con i cookie nel browser per comodità.
Se vuoi essere un stickler HTTP, il tuo HTTP deve essere stateless (e forse RESTful).
La scelta comune è POST, e ha senso. I verbi "sicuri" (GET, HEAD, OPTIONS, TRACE) sono fuori, perché non possono avere effetti collaterali semantici che cambiano lo stato osservabile dell'applicazione (e l'accesso è tale stato) .
PUT e DELETE sono possibilità teoriche; la risorsa che si sta creando (PUT) e la rimozione (DELETE) sarebbero la sessione dell'utente. Tuttavia, ci sono alcune stranezze su questo: prima di tutto, PUT e DELETE, mentre non sono sicuri come HEAD, dovrebbero ancora essere idempotenti , cioè, effettuare il logout più volte di seguito senza registrare back in dovrebbe essere valido, e quindi accederà di nuovo mentre è ancora loggato. Inoltre, tale doppio login non può alterare lo stato dell'applicazione oltre quello che fa il primo login, che, considerando cose come gli ID di sessione e così via, è problematico. Inoltre, a rigor di termini, l'URL che stai trasmettendo dovrebbe identificare in modo univoco la risorsa che stai spingendo, quindi per essere semanticamente corretto, dovresti mettere a link anziché link , ovvero un identificatore univoco per la sessione dovrebbe essere codificato nel URL - ma poi, l'ID di sessione viene generato insieme alla sessione, quindi l'ID non esiste ancora fino a quando dopo login riuscito.
La semantica del POST è molto più adatta: il tuo URL di accesso (ad esempio, link ) identifica una risorsa (la funzionalità di accesso dell'applicazione ') che stai per "annotare", cioè cambia un aspetto di quella risorsa. A differenza di PUT e DELETE, le richieste POST non devono essere idempotenti, il che significa che più richieste POST identiche possono continuare a cambiare lo stato dell'applicazione - questo è esattamente quello che vuoi.
La descrizione di Wikipedia dei vari verbi è in realtà piuttosto rivelatrice in questo senso:
Voglio solo chiarire la risposta accettata su come effettuare il logout, uso POST per una risorsa di sessione ( link ) per Login e il la risposta include una posizione della sessione appena creata ( link ).
Per disconnettersi, ELIMINA la risorsa di sessione indicata dalla posizione dalla risposta POST.
Puoi accedere / disconnettersi più volte. Solo il primo DELETE non restituisce alcun contenuto (204), dopodiché dovrebbe restituire la risposta non trovata (404). L'accesso più volte creerà più sessioni.