Sembra che tu stia confondendo gli oggetti del modello sottostante con le tue risorse API, non necessariamente si escludono a vicenda. Se stai semplicemente serializzando le tue classi come JSON, dovrai duplicare il contenuto (e far apparire il profilo diverse volte) che non è necessario e un odore.

Potresti:

Crea modelli di risorse specifici che rappresentano meglio le tue risorse (un po 'come Visualizza i modelli in un framework MVC). In questo modo è possibile creare oggetti modello come PatientResource , XRayResource e AllergyResource (non è necessario suffragare il nome Risorsa qui, potrebbero semplicemente sedersi da qualche parte separatamente rispetto agli altri modelli). questo rappresenta meglio ciò che i tuoi clienti hanno bisogno di consumare invece di ogni proprietà del modello di dominio.

c # qui:

public class PatientResource
{
    public int Id { get; set; }
    public IEnumerable<AllergyResource> Allergies { get; set; }
    public IEnumerable<XrayResource> XRays { get; set; }
}

public class AllergyResource
{ 
    public int Id { get; set; }
    public string Name { get; set; }
    public int ProfileId { get; set; }
}

public class XrayResource
{ 
    public int Id { get; set; }
    public string Name { get; set; }
    public int ProfileId { get; set; }
}

Tutte le risorse di base, le allergie e i raggi x non contengono oggetti profilo, contengono un riferimento per un profilo, anche se apparirebbero leggermente fuori posto, quindi potrebbe essere necessario limitare alcune proprietà a seconda di dove sono i tuoi dati consumato, ad esempio, hai davvero bisogno di mostrare un profiloId se rappresenti un AllergyResource nella raccolta AllergyResource di un PatientResource , probabilmente no, quindi per quella serializzazione dovresti omettere quella proprietà. Tuttavia, se tu fossi in una percentuale stand_one% di co_de probabilmente vorresti mostrare il riferimento.

Mi piace utilizzare i link nella mia API

Non so davvero quale tipo di API stai creando (RESTFul, RPC, HATEOS ecc.), quindi questo potrebbe non essere applicabile. Mi occupo principalmente dello stile REST (alcuni potrebbero non essere REST nel vero senso della parola) ma quando costruisco un'API mi piace essere il più sintetico possibile con i miei oggetti risposta, ma dare ai clienti la possibilità di scoprire risorse collegate tramite collegamenti. Questo può essere complicato o semplice come vuoi, puoi usare JSON o un tipo di media più specifico come HAL + JSON ma il punto è, tu mandi le tue risorse nel filo, e abiliti la scoperta-abilità delle risorse correlate via standard Link HTTP.

BasecampX come esempio: dove hanno una persona, ma il L'elenco delle cose da fare è disponibile su un altro endpoint della risorsa specificato nella risposta. Gli oggetti sono semplificati, ma rende la chiamata dell'API più dettagliata in quanto sono richieste più richieste. Dipende davvero da come i tuoi clienti consumeranno i dati e lavoreranno con esso.