utenti / me sembra una cattiva idea perché REST preferisce avere un URL per risorsa. Avrai quindi:
utenti / me
utenti / 123myId
Che puntano alla stessa risorsa. Se lavori con gli hateos, inserisci un link alla tua risorsa.
Quindi riguardo alle e-mail: Un URL dovrebbe, a mio parere, non avere dati confidenziali o privati al suo interno. Ad esempio: l'url può essere utilizzato per la registrazione, il caching, ecc. Crea un luogo in cui sono elencati uno o più indirizzi e-mail.
Questi potrebbero essere usati per spam, tentativi di accesso, ecc.
Vedi anche:
link
Quindi, no, non lo farei.
2016: risposta al commento:
Siamo d'accordo che camminiamo su url / uris a questo punto. Non esattamente la stessa cosa, cerca la differenza. Roy Fielding è citato alcune volte di seguito, è l'inventore del REST link e altre tecnologie correlate.
In generale è scritto come: Url per identificare una risorsa. Prendo questo come: Un URL di risorsa uno ma non è una regola difficile.
Il link parte 5.2.1.1 è interessante su questo argomento. "REST si basa invece sull'autore che sceglie un identificatore di risorsa che meglio si adatta alla natura del concetto identificato". Quindi hai la libertà di scegliere, quindi perché non scegliere più url per la stessa risorsa?
In questo caso specifico:
link
Parte: 6.2.5 "Una forma di abuso consiste nell'includere informazioni che identificano l'utente corrente in tutto l'URI a cui fa riferimento una rappresentazione di risposta ipermediale."
Sono stato fortunato e ho trovato una risposta abbastanza specifica a questo caso, come puoi vedere sopra. La stessa parte discute anche alcuni dei problemi di memorizzazione nella cache che potrebbero verificarsi.
In generale su REST e URL: non ho trovato la prova che una risorsa === 1 url. Ma, in pratica, non mi piace. Avrai più URL meno chiari: "Qui puoi trovare quella risorsa, ma anche qui, e qui.". In HATEOAS cosa definirai come link a _self? Una serie di URL?
W3 ha pubblicato un post interessante sull'utilizzo degli URL: link
Stability. Once you set up a URI to identify a certain resource, it
should remain this way as long as possible. Think about the next ten
years. Maybe twenty. [...]
Molto più interessante da leggere in quel post in cui puoi trovare numerosi argomenti per mantenere stabile l'URL.
E: link su "Non pensavo che gli URL dovessero essere persistenti - erano URN".
BUT: Ora concentriamoci solo su REST, perché gli URL sono molto più usati come si vede negli articoli precedenti.
link
A REST API must not define fixed resource names or hierarchies (an
obvious coupling of client and server). Servers must have the freedom
to control their own namespace. Instead, allow servers to instruct
clients on how to construct appropriate URIs, such as is done in HTML
forms and URI templates, by defining those instructions within media
types and link relations. [Failure here implies that clients are
assuming a resource structure due to out-of band information, such as
a domain-specific standard, which is the data-oriented equivalent to
RPC’s functional coupling].
Quindi, il server informa il cliente sugli URL corretti da utilizzare. Non c'è nessuna ipotesi su quale dovrebbe essere l'url, dice il server. O fornendo URL complessi o fornendo modelli di URL: link . Quindi in questo senso non importa troppo, i tuoi client funzioneranno anche quando il server cambia struttura url.
Ciò ha anche rimosso parte del vantaggio di avere 2 URL per la stessa risorsa, ad esempio / customers / 1 e / user / 123 / customer / 1 perché non è qualcosa che un essere umano dovrebbe interpretare e / o modificare da solo.
Quindi nei commenti su quel post di Roy Fielding:
A truly RESTful API looks like hypertext. Every addressable unit of
information carries an address, either explicitly (e.g., link and id
attributes) or implicitly (e.g., derived from the media type
definition and representation structure).
e
Any important resource in a RESTful system must have an identifier [...]
Questo, per me, è abbastanza diretto da mantenere un URL per risorsa. Quindi, per riassumere: non ho trovato una rigida regola severa, ma l'intenzione e i vantaggi di avere una risorsa === un url per me sono sufficienti per attenervisi. I vantaggi di avere più URL non sembrano essere molto disponibili tranne quando inizi a creare manualmente URL che non sembrano essere l'intenzione.
Per ulteriori risposte potresti porre questa domanda allo stesso Roy Fielding.