Ci sono alcune cose che rendono questa API non molto RESTful:
Gli URL dell'API REST identificano le risorse, non le azioni. In primo luogo, le azioni non devono far parte del percorso dell'URL. Le azioni sono i diversi metodi HTTP. Invece di fare qualcosa come GET /api/person/findByEmail/[email protected] , dovresti rimuovere findByEmail e utilizzare i parametri di ricerca per comunicare che stai cercando tramite email, ad es. %codice%. Notare che sono anche cambiato da persona a persone , poiché le raccolte dovrebbero generalmente essere indicate come plurali delle risorse che contengono. Questa risorsa viene visualizzata come "Persone che hanno l'indirizzo email [email protected]" e con il metodo GET la richiesta diventa "Ricevi le persone che hanno l'indirizzo email [email protected]".
In secondo luogo, PUT dovrebbe sempre essere idempotente, e il modo in cui lo stai usando non lo è. In altre parole, se il metodo PUT viene chiamato accidentalmente più volte di quanto previsto, non avrà molta importanza.
Quando utilizzare PUT: quando posiziona una risorsa in una posizione specifica, ad es. se vuoi mettere una risorsa canzone a GET /api/[email protected] . Se questo viene chiamato più di una volta, non avrà un risultato diverso. Nota, posizionare qualcosa potrebbe anche significare mettere qualcosa che non era precedentemente nel sistema. PUT può creare una risorsa sul back-end o nel livello di persistenza da qualche parte se non esiste già prima di collocarlo nella posizione specificata. Il punto chiave qui è che non stai dicendo 'crea un utente e dammi un URL per fare riferimento a tale utente', stai dicendo 'crea un utente simile a questo e metti l'utente a questo URL'. Questa richiesta potrebbe essere "Metti la canzone seguente come prima traccia nella playlist 5"
Quando usare POST: quando crea una risorsa, e tocca al server creare un URL per la risorsa. Un esempio potrebbe essere la creazione di un utente, proprio come si sta tentando di fare, che potrebbe essere fatto in questo modo: /api/playlists/5/tracks/1 . Un altro modo per farlo sarebbe semplicemente utilizzare POST /api/people?firstName=Sally&lastName=Smith&[email protected] e passare come corpo della richiesta un oggetto persona contenente tali dettagli, ad esempio:
{
firstName: "Sally",
lastName: "Smith",
email: "[email protected]"
}
La risposta avrebbe un'intestazione POST /api/people che indica che la risorsa persona vive in quell'URL. Se lo chiami una seconda volta, potrebbe darti Location : api/people/1 . Ogni successivo POST dovrebbe darti un nuovo URL per la risorsa appena creata perché stai creando uno nuovo ogni volta che viene chiamato. Si noti che, per loro natura, le richieste POST sono generalmente non idempotenti.
Quindi qualunque cosa sia, non la chiamerei REST. Per quanto riguarda ciò che puoi chiamarlo, direi che dipende da te. Immagino che dovresti chiederti se conta davvero come lo chiami e se c'è qualcosa di sbagliato nel chiamarlo semplicemente una "websockets API".