Che tipo di identificatore dovrebbe andare in un URL RESTful

Oltre alla risposta di VoiceOfUnreason (che ho concordato con).

what if I wanted to get the products for a given customer and I don't model customers in my system?

Se consideriamo il citato RFC 3986 - Percorso e il fatto che i clienti non fanno parte del modello (quindi, nessuna parte dell'API), probabilmente i seguenti URI sono più appropriati

/myservice/products/?q=customer:12345
/myservice/products/?customer=12345

Secondo la domanda, customers sembra essere solo un attributo ( product.customer ). Senza gerarchia. Quindi, perché esprimere la gerarchia dove non c'è?

Qualsiasi URI andrà comunque bene. Gli URI non hanno nulla a che fare con REST. Ci si aspetta che non abbiano alcun significato poiché gli unici lettori sono altre applicazioni (principalmente client HTTP). Ricorda cosa significa URI (risorsa uniforme identificatore ). ¹

Considerazioni

Se prevedi la possibilità di implementare customers in un prossimo futuro, potrebbe essere opportuno non utilizzare /customer qualsiasi luogo (ancora) poiché la rappresentazione delle risorse a cui fa riferimento questi percorsi potrebbe cambiare. Causando possibili interruzioni delle modifiche ai client. Ovviamente, è una congettura, ma non vale la pena di essere a conoscenza delle possibilità che la tua API cambierà.

Le API Web possono essere davvero resilienti quando rispettiamo tutti i principi di REST, ma la mia esperienza mi dice che questo non è il caso nella maggior parte delle API là fuori. Quando non adottiamo pienamente REST (in particolare HATEOAS), i consumatori di API usano abbastanza l'URI e i modelli di dati. In questi casi, le API Web e le modifiche non vanno d'accordo.

^{1: Le due alternative suggerite cercano solo di soddisfare la necessità di "espressività" (ciò che OP sta cercando) e di comunicare con le pratiche comuni dei progetti di API web. Nessuno dei due richiesti da REST.}

REST non si cura di quale ortografia si usa per l'URI; qualsiasi informazione codificata nell'identificatore viene effettuata a discrezione del server e per suo uso esclusivo.

Would this be acceptable? /myService/products/customer/999

Sì, va bene.

Alcuni potrebbero obiettare che è semanticamente scorretto - RFC 3986: Path

The path component contains data, usually organized in hierarchical form

Il "/" letterale è usato per separare i segmenti nella gerarchia; quindi il tuo spelling suggerisce che il "cliente" è subordinato ai prodotti nella gerarchia, il che probabilmente non ha senso semanticamente.

È molto simile alla creazione di una directory "cliente" nella directory "prodotti" nel tuo file system.

Per quanto riguarda un parser URI, l'ortografia /myService/products/customer/999 è perfettamente valida. Ma un essere umano che abbia familiarità con i significati di products e customer potrebbe essere sorpreso dalla relazione subordinata implicita.

C'è un valore nella scelta di una grafia meno sorprendente? Forse.