Rest api con una risorsa hello / punto di ingresso principale

La tua domanda è complicata, in quanto molte persone non sono d'accordo su cosa sia realmente un'API REST. L'unica risposta autoritaria - ma purtroppo "troppo concettuale" - è la tesi di dottorato di Roy Fielding . Quindi, in base alle tue esigenze, aderirai ai diversi livelli dei principi REST.

Quali sono i requisiti dei tuoi clienti? Hai davvero bisogno di soddisfare i i 3 livelli di maturità di REST? Soprattutto il terzo, che prevede che un client faccia più richieste per costruire il proprio stato dell'applicazione (piuttosto che gli URI "hardcoded" che hanno anche alcuni vantaggi!)

Diciamo che vuoi aderire rigorosamente a REST seguendo con verbi, risorse e materiale HATEOAS. Il primo passo è creare un punto di ingresso principale che sarà il punto di partenza del tuo cliente. Un client che recupera questo punto di ingresso principale attraverso una risorsa, avrà alcuni collegamenti che reindirizzano alle risorse differenti (le risorse che si mettono dipendono dall'architettura del software!). Qui, probabilmente avrai un link alla risorsa ciao.

Non ho capito perché hai bisogno di un token reader , ma i token sono una pratica comune per avere un tipo di autorizzazione "stateless" in quanto il tuo server non memorizza alcuna informazione sul client, perché il token è detenuto dai client.

Dovresti anche notare che se inizi a trattare con HATEOAS, sarà necessario disporre di un formato ipermediale. JSON non è un formato ipermediale, non esiste alcuna nozione di link in questo formato. Ma esiste un sacco di formati ipermediali (Siren, HAL, Hydra, ecc ...) che sono stati proposti.

Una delle caratteristiche di un'API RESTful è HATEOAS (Hypertext come motore dello stato dell'applicazione). HATEOAS implica che "un client REST inserisce un'applicazione REST attraverso un URL fisso semplice" (citato da Wikipedia ). Quindi sì, è comune alle API REST avere una risorsa che i client usano come primo passo.

HATEOAS mira a disaccoppiare client e server. Se esistessero più punti di accesso, i client non solo avrebbero dovuto conoscere l'URI di un punto di ingresso, ma l'URI di tutti i punti di ingresso. Non sarebbe possibile modificare questi URI senza influenzare i client. Se l'utente deve essere in grado di scegliere prima cosa fare, allora l'API dovrebbe offrire una risorsa contenente un collegamento per ogni cosa che l'utente potrebbe fare prima. Questi URI possono quindi cambiare senza influenzare i client.

Inoltre, un singolo punto di ingresso ci consente di abilitare / disabilitare determinate funzionalità lato server. I client non offriranno funzionalità quando non hanno i collegamenti corrispondenti. Probabilmente ti stai riferendo a questo vantaggio nella tua domanda ("i clienti non provano ad accedere a molte altre risorse che fallirebbero").

Potresti usare il punto di ingresso anche per inizializzare una sessione, almeno questo è quello che capisco dalla tua domanda ("Allega logica di registrazione lato server" e "restituisci un token lettore"), ma fai attenzione a tenere il lato server le informazioni sulla sessione potrebbero essere dannose per la scalabilità.