Reading resources online, one can get the idea that the REST API is seen kind of like an adapter to the database.
È vero, puoi avere questa idea. Non è giusto. L'API REST potrebbe essere un adattatore per qualsiasi numero di diverse implementazioni. Questo è parte del motivo per cui lo stile architettonico REST è stato così efficace; client e server sono in grado di collaborare senza la necessità di conoscere i rispettivi interni.
Risposta breve: tutte le tue scelte vanno bene.
Il primo pezzo da capire è il concetto di risorsa nel Stile architettonico REST.
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
"Utente corrente" e "settimana corrente" sono concetti perfettamente ragionevoli, quindi ovviamente possono essere risorse. "Settimana corrente" è solo una mappatura che si evolve rispetto a un orologio, "Utente corrente" è solo una mappatura per l'operatore associato alla richiesta corrente. Non ci sono problemi lì.
Come osserva Ewan, REST è senza stato - più precisamente, lo stile architettonico REST non ti permette di memorizzare client stato sul server . In pratica significa che il messaggio restituito dal server può considerare solo lo stato del server combinato con i dati forniti nella richiesta. Un altro modo di pensare a questo: alle richieste del cliente non è permesso usare pronomi senza includere l'antecedente.
Quindi assumendo che "l'utente corrente" si riferisca al client (ad esempio, l'operatore umano che lavora nel browser), nella richiesta devono esserci alcuni dati che comunicano l'utente di cui stiamo parlando. Potrebbe trattarsi di informazioni codificate nell'identificativo della risorsa stessa, oppure potrebbe essere incluso nei metadati della richiesta (ad esempio, HTTP ha un Autorizzazione intestazione che potrebbe contenere questi dati).
Naturalmente, parte del punto della "settimana corrente" è che cambia; la prossima settimana è diversa dalla scorsa settimana. Alice e Bob sono diversi "utenti correnti". Pertanto, è necessario prestare una certa attenzione con la memorizzazione nella cache ; assicurandosi che il server comunichi chiaramente (tramite i metadati) a chi è autorizzato a leggere le copie della rappresentazione corrente, e in che modo per quanto tempo tale rappresentazione può essere considerata valida.
Per alcuni scenari di memorizzazione nella cache, può essere utile collegare la risposta a una risorsa diversa con un identificatore "canonico". /user/alice potrebbe essere l'identificatore canonico di /me quando viene elaborata la richiesta di Alice; /2017-W48 potrebbe essere l'identificatore canonico per /current-week . Per vari casi d'uso, potresti reindirizzare una richiesta alla risorsa canonica, anziché gestirla immediatamente.