api - 这个 API 是不是太简单了？

Question

有大量可用的键值对存储。目前你需要选择一个并坚持下去。我相信一个独立的开放 API，不是由键值存储供应商制作的，将使存储之间的切换变得更加容易。

因此，我正在构建一个数据存储抽象层（如 ODBC，但专注于更简单的键值存储），以便有人构建一次应用程序，并在必要时更改键值存储。这个 API 是不是太简单了？

get(Key)
set(Key, Value)
exists(Key)
delete(Key)

到目前为止，我看到的所有 API 似乎都增加了很多，我想知道需要多少额外的方法？

我收到一些回复说 set(null) 可以用来删除一个项目，如果 get 返回 null 那么这意味着一个项目不存在。这很糟糕，有两个原因。首先，混合返回类型和状态不是很好，其次，不是所有的语言都有 null 的概念。看：

我确实希望能够对数据执行多种类型的操作，但据我了解，一切都可以建立在键值存储之上。它是否正确？我也应该提供这些增值功能吗？例如：像 mapreduce 或索引

在内部，我们已经在 Erlang 和 Ruby 中有一个基本版本，它为我们节省了大量时间，还使我们能够测试不同键值存储的特定用例的性能

score 6 · Accepted Answer

只做绝对必要的事，不要问是否太简单，而要问是否太多，即使只有一种方法。

score 4 · Accepted Answer

4

如果您所做的只是获取、设置和删除密钥，这很好。

于 2010-02-23T20:57:27.680 回答

score 4 · Accepted Answer

您的 API 缺少一些有用的功能，例如“hasKey”和“clear”。例如，您可能想查看 Python 的 hack，http://docs.python.org/tutorial/datastructures.html#dictionaries，然后选择其他函数。

每个人都在说，“简单就是好”，直到“简单太简单”之前都是如此。

score 3 · Accepted Answer

对于 API，没有“太简单”这样的事情。越简单越好！如果它按原样解决了需求，那就离开它。

score 3 · Accepted Answer

该delete方法是不必要的。你可以直接null传给set.

编辑添加：

我只是在开玩笑！我会继续删除，并可能添加计数、包含，也许还有一个（或两个）枚举器。

score 2 · Accepted Answer

我完全赞成将接口简化到最低限度，但没有关于系统要求的更多细节，很难判断这个接口是否足够。当然看起来足够简洁。

不要忘记记录“密钥不存在”的语义，因为阅读上面的 API 定义并不清楚。更新：我看到你已经添加了exists方法：这是必要的吗？您可以使用该get方法并定义NIL某种，不是吗？

也许值得思考：考虑一个值的“新鲜度”怎么样？即关联的“最后修改”时间戳？当然，这取决于您的系统要求。

访问控制呢？它是否在 API 定义的范围内？

遍历键呢？如果可能有一个大集合，您可能需要包含一些分页语义。

score 2 · Accepted Answer

创建 API 时，您需要问自己，我的 API 为用户提供了什么。如果您的 API 过于简单，以至于您的客户可以更快、更轻松地编写自己的应用程序，那么您的 API 就失败了。问问自己，我的功能是否给他们带来了特定的好处。如果答案是否定的，那就太简单化和笼统了。

score 1 · Accepted Answer

如前所述，越简单越好，但可以使用简单的迭代器或键列表方法。我总是最终需要遍历集合。一个“size()”方法，如果不被迭代器处理的话。不过，这显然取决于您的使用情况。

score 0 · Accepted Answer

这不是太简单，它很漂亮。如果 "exists(key)" 只是 "get(Key) != null" 的一种方便的简写，您应该考虑将其删除。我想这取决于您 get() 的值有多大或有多复杂。

9 回答 9