Is this API too simple?

Question

There are a multitude of key-value stores available. Currently you need to choose one and stick with it. I believe an independent open API, not made by a key-value store vendor would make switching between stores much easier.

Therefore I'm building a datastore abstraction layer (like ODBC but focused on simpler key value stores) so that someone build an app once, and change key-value stores if necessary. Is this API too simple?

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

As all the APIs I have seen so far seem to add so much I was wondering how many additional methods were necessary?

I have received some replies saying that set(null) could be used to delete an item and if get returns null then this means that an item doesn't exist. This is bad for two reasons. Firstly, is it not good to mix return types and statuses, and secondly, not all languages have the concept of null. See:

Do all programming languages have a clear concept of NIL, null, or undefined?

I do want to be able to perform many types of operation on the data, but as I understand it everything can be built up on top of a key value store. Is this correct? And should I provide these value added functions too? e.g: like mapreduce, or indexes

Internally we already have a basic version of this in Erlang and Ruby and it has saved us alot of time, and also enabled us to test performance for specific use cases of different key value stores

Answer 1

Do only what is absolute necessary, instead of asking if it is too simple, ask if it is too much, even if it only has one method.