Prima di tutto, progetterai un'API molto povera se stai pensando a "chiavi esterne" mentre progetti questa API. In qualità di progettista API, la tua attività commerciale è risorse , non entità o chiavi .
Se pensi in termini di risorse, la risposta è davvero ovvia. Hai una risorsa incorporata (ordini appartenenti a un cliente) o hai una query.
Le risorse incorporate sono come sottodirectory. Utilizza il percorso per questo:
/api/customers/4/orders
E una query è, non sorprendentemente, una stringa di query:
/api/orders?customerId=4
Oppure, alcune persone pensano che questo sia più RESTful:
/api/orders?customer=/api/customers/4
Tutti questi sono a posto. È in parte una questione di preferenza e in parte una questione di quanto siano complesse le tue relazioni.
Ma una cosa è certa, sei sulla strada sbagliata parlando di cose chiavi primarie e chiavi esterne. Questi sono termini di database e le API non hanno nulla a che fare con il tuo database. Non è affatto raro avere rappresentazioni multiple della stessa risorsa, ad esempio:
/api/customers/123/
/api/customers/acme+inc/
/api/customers/123-acme+inc/
/api/customers/123/acme+inc/
/api/customers/me/ (say you are ACME Inc.)
L'intera idea di un'API REST è che questi identificatori di risorse (URI) sono opachi. Non sai cosa sia la "chiave primaria" e potresti non essere del tutto sicuro di cosa sia "ID". Quindi, ancora una volta, ripetendo ancora una volta il record, non utilizzare la terminologia del database quando si ragiona su un'API Web, questo porterà alla progettazione sbagliata.