获取列表并返回列表的API。

Question

所以我和一些同事讨论了一下，想象一下我在设计一个API。API接受一个ID列表，并返回每个ID的对应对象列表，每个ID对应于一个对象，如果没有找到任何ID，则整个调用失败。返回的对象不具有用于查询它们的ID，而是按照传递给API的元素的相同顺序返回。

1,3,5 -> obj-1，obj-3，obj-5

因此，我的问题是，如果API中详细记录了这一点，调用方知道哪个项对应于每个ID，因为它们是按照相同的顺序传递的。唯一将输入与结果联系起来的东西是顺序，这似乎是天生的错误设计，但一位同事坚持这是API中接受输入列表的一种常见做法。

像这样设计API有什么本质上的坏处吗？

Answer 1

结果顺序是一个非常严格的协议，使得API不那么灵活。

如果没有id的数据，会发生什么？因此，我的建议是返回一个包含id : data对的集合：

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

或者，如果您有多个id的数据：

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

Answer 2

实际上，如果一个API正在实现隐式行为，那么它的设计是错误的。如果您将接口和方法签名视为契约(例如，我保证您将得到一个列表，如果您给我一个列表)给调用者。

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

如果你认为每一种公开的方法都是黑匣子，那么你就不能依赖几周前做出的承诺。如果您把它放得更长一些，term...the接口，也就是方法签名没有改变。但是如何实现呢？

因此，IMHO通过接口aka方法签名提供一个完整的契约要好得多。例如。

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

现在你不用考虑命令了。当然，您应该考虑dit描述的null案例。