API che prende una lista e restituisce una lista

Question

API che prende una lista e restituisce una lista

#1 da (6 voti)
#2 da (0 voti)

1

Quindi stavo avendo una discussione con alcuni colleghi di lavoro, immagino che stia progettando un'API. L'API accetta un elenco di ID e restituisce un elenco di oggetti corrispondenti per ciascun ID, ciascun ID corrisponde esattamente a 1 oggetto e se non viene trovato alcun ID, l'intera chiamata non riesce. Gli oggetti restituiti non hanno l'ID usato per interrogarli, ma vengono restituiti nello stesso ordine degli elementi passati all'API.

cioè 1,3,5 - > obj-1, obj-3, obj-5

Quindi la mia domanda è, se questo è ben documentato nell'API, che il chiamante sappia quale elemento corrisponde a ciascun ID perché sono passati nello stesso ordine. Sembra che il design intrinsecamente sbagliato abbia l'unica cosa che lega l'input al risultato è l'ordine, ma un collaboratore insiste che questa è una pratica comune nelle API che contengono elenchi di input.

C'è qualcosa di intrinsecamente negativo nel progettare un'API come questa?

design api

posta KDiTraglia 08.03.2018 - 05:23

fonte

2 risposte

Leggi altre domande sui tag design api

Regola del pollice per quando utilizzare una correzione rapida? Gestisce la compatibilità con le versioni precedenti delle modifiche API

score 6 · Answer 1

L'ordine dei risultati è un accordo molto stretto e rende l'API meno flessibile.

Che cosa accadrà, se non ci sono dati per l'ID? Quindi il mio suggerimento è di restituire una collezione con id : data pairs:

{
  "1" : "obj-1",
  "2" : "obj-2",
  "3" : null,
  "4" : "obj-4"
}

O se hai più dati per un id:

{
  "1" : ["obj-1a", "obj-1b"],
  "2" : ["obj-2"],
  "3" : [],
  "4" : ["obj-4"]
}

score 0 · Answer 2

In realtà, è una cattiva progettazione, se un'API sta implementando un comportamento implicito. Se consideri le interfacce e le firme dei metodi come un contratto (ad esempio, ti garantisco che otterrai un elenco, se mi dai un elenco) al chiamante, ad es.

public IList<SomeClass> GetAListForAList(IList<int> inputList)
{
    // some code here ...
}

Se consideri ogni metodo pubblico come una scatola nera, non puoi fare affidamento su un impegno preso poche settimane fa. Se lo metti più a lungo termine ... l'interfaccia aka firma del metodo non cambia. Ma per quanto riguarda l'implementazione?

Quindi IMHO è molto meglio fornire un contratto completo tramite l'interfaccia, ovvero la firma del metodo. Per es.

public IDictionary<int, SomeClass> GetAListForAList(IList<int> inputList)
{
   // some  code here
}

Ora non devi pensare all'ordine. Ovviamente dovresti pensare al caso null descritto da dit.