Per essere il più riposante possibile, un login utente è stato progettato meglio usando un GET o un POST su un webservice REST? E perché?
Per essere il più riposante possibile, un login utente è stato progettato meglio usando un GET o un POST su un webservice REST? E perché?
GET dovrebbe essere usato per ottenere una rappresentazione di una risorsa. PUT - per aggiornare o sostituire una risorsa esistente. Pertanto, per eseguire l'azione di login, POST è migliore.
Userei un POST, poiché apporta modifiche serie allo stato del server (anche se non è stato salvato nel database). Anche se è più una regola HTTP che REST.
Questo articolo su InfoQ mi ha aiutato a comprendere REST. Parafrasando dalla sezione Utilizza metodi standard :
PUT means, essentially: "update this resource with this data, or create it at this URI if it’s not there already", whereas POST means "create a new resource."
Secondo IBM DeveloperWorks però:
- To create a resource on the server, use POST.
- To change the state of a resource or to update it, use PUT.
Sulla base di queste definizioni, se si intende aggiornare continuamente un qualche tipo di token di accesso per indicare che un utente è ancora connesso, utilizzare POST per crearlo, quindi PUT per aggiornarlo su richieste successive.
Inoltre, dalla sezione Comunicare senza stato :
REST mandates that state be either turned into resource state, or kept on the client. In other words, a server should not have to retain some sort of communication state for any of the clients it communicates with beyond a single request. The most obvious reason for this is scalability — the number of clients interacting would seriously impact the server’s footprint if it had to keep client state. (Note that this usually requires some re-design — you can’t simply stick a URI to some session state and call it RESTful.)
But there are other aspects that might be much more important: The statelessness constraint isolates the client against changes on the server as it is not dependent on talking to the same server in two consecutive requests. A client could receive a document containing links from the server, and while it does some processing, the server could be shut down, its hard disk could be ripped out and be replaced, the software could be updated and restarted — and if the client follows one of the links it has received from the server, it won’t notice.
Dato questo, sembra che non dovremmo creare nessuno stato del server per tenere traccia degli utenti che hanno effettuato l'accesso; piuttosto dovremmo forse usare l'autenticazione HTTP.
Ecco un'altra buona domanda relativa al problema dell'autenticazione per i servizi REST.