Gestione degli aggiornamenti delle raccolte secondarie in Web API

Naviga le tue risposte
0

Prendiamo un esempio classico di impresa: Order e OrderItem 

public class Order
{
    public Guid Id { get; set; }
    public ICollection<OrderItem> Items { get; set; }
}

public class OrderItem
{
    public Guid Id { get; set; }
    //...
}

Ora, qual è il modo più ragionevole per aggiornare gli articoli dell'ordine utilizzando PUT o PATCH (Patch JSON)?

Dovrei PUT api/orders/{id} con una nuova collezione (con elementi rimossi, aggiunti o aggiornati) o gestirla in modo diverso in qualche modo? Ad esempio, invece di restituire una raccolta serializzata di elementi, l'elenco di resi o i collegamenti per ciascun elemento come: api/orders/{id}/items/{id} . Quindi sarebbe più HATEOAS come e REST come ... 

public class Order
{
    public Guid Id { get; set; }
    public ICollection<Link> Items { get; set; }
}

Quindi se volessi aggiornare o rimuovere alcuni elementi dall'ordine userei quei link, ma il lato negativo di questo è che l'implementazione lato client non sarà così semplice.

L'altra soluzione a cui riesco a pensare è restituire id di elementi come: 

public class Order
{
    public Guid Id { get; set; }
    public ICollection<Guid> Items { get; set; }
}

ma non sembra troppo bello per me, quindi qual è più o meno lo standard del settore per affrontare questo?

  • Restituzione di elementi incorporati
  • Restituzione degli URL degli articoli
  • Restituzione degli ID oggetto
posta Konrad 06.09.2018 - 11:00
fonte

1 risposta

2

Se Order ha gli OrderItem allegati, dovresti semplicemente aggiornare Order e non fornire i metodi api per OrderItems.

così 

public class Order
{
    public Guid Id { get; set; }
    public ICollection<OrderItem> Items { get; set; }
}

api/orders/UpdateOrder {"Id" : "guid" "Items" : [{...},{...}] }
api/orders/GetOrderById

Se OrderItem ha solo un OrderId e Order non contiene un elenco di essi, allora dovresti avere metodi API per OrderItems

così. 

public class Order
{
    public Guid Id { get; set; }
}

public class OrderItem
{
    public Guid Id { get; set; }
    public Guid OrderId { get; set; }
}

api/orders/UpdateOrder {"Id" : "guid"}
api/orders/GetOrderById

api/orders/UpdateOrderItem {...}
api/orders/GetOrderItemsByOrderId
api/orders/DeleteOrderItem

* evitando i verbi HTTP per chiarezza

A prima vista l'oggetto complesso / aggregato / primo approccio sembra molto superiore. Ma man mano che l'oggetto inizia a ingrandirsi e hai bisogno solo di alcuni oggetti figlio per determinate operazioni, il secondo approccio può diventare più efficiente.

Ad esempio, puoi immaginare che potrei voler conoscere e fare molte cose su / con un oggetto aziendale senza caricare l'Elenco di tutti i suoi dipendenti passati e presenti ogni volta.

    
risposta data 06.09.2018 - 11:05
fonte

Leggi altre domande sui tag

Se i passaggi del flusso di lavoro di un'azienda possono risiedere esclusivamente in un database, esiste un motivo per utilizzare un motore di flusso di lavoro per eseguire tali passaggi? In quale livello sono memorizzati i DTO con CQRS?