Является ли этот API слишком простым?

Существует множество магазинов с ключевыми значениями. В настоящее время вам нужно выбрать один и придерживаться его. Я считаю, что независимый открытый API, не созданный поставщиком хранилища ключей, значительно облегчит переключение между магазинами.

Поэтому я создаю слой абстракции хранилища данных (например, ODBC, но сосредоточен на более простых хранилищах ключевых значений), чтобы кто-то однажды создавал приложение и при необходимости менял хранилища ключей. Является ли этот API слишком простым?

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

Поскольку все API-интерфейсы, которые я видел до сих пор, похоже, так много добавили, мне было интересно, сколько дополнительных методов было необходимо?

Я получил несколько ответов о том, что set (null) можно использовать для удаления элемента, и если get возвращает null, это означает, что элемент не существует. Это плохо по двум причинам. Во-первых, нехорошо смешивать типы и состояния возврата, а во-вторых, не все языки имеют понятие null. См:

У всех языков программирования есть четкое представление о NIL, null или undefined?

Я хочу иметь возможность выполнять много типов операций с данными, но, как я понимаю, все может быть создано поверх хранилища значений ключей. Это верно? И должен ли я предоставлять эти функции с добавленной стоимостью? например: например mapreduce или индексы

Внутри у нас уже есть базовая версия этого в Erlang и Ruby, и это сэкономило нам много времени, а также позволило нам проверить производительность для конкретных случаев использования разных хранилищ значений ключей

Ответ 1

В вашем API отсутствуют некоторые полезные функции, такие как "hasKey" и "clear". Вы можете посмотреть, скажем, на Python, http://docs.python.org/tutorial/datastructures.html#dictionaries и выбрать и выбрать дополнительные функции.

Все говорят: "простое добро", и это правда, пока "простое слишком просто".

Ответ 2

Сделайте только то, что абсолютно необходимо, вместо того, чтобы спросить, слишком ли оно просто, спросите, слишком ли это, даже если у него есть только один метод.

Ответ 3

Если все, что вы делаете, это получение, установка и удаление ключей, это нормально.

Ответ 4

В API нет такой вещи, как "слишком простой". Чем проще, тем лучше! Если он решает проблему так, как он есть, то оставьте его.

Ответ 5

Метод delete не нужен. Вы можете просто передать null в set.

Отредактировано для добавления:

Я просто шучу! Я бы продолжал удалять и, вероятно, добавлял Count, Contains и, возможно, счетчик (или два).

Ответ 6

Я все для упрощения интерфейса до его минимального минимума, но не имея более подробной информации о требованиях системы, трудно сказать, достаточно ли этого интерфейса. Конечно, выглядит достаточно кратким, хотя.

Не забывайте документировать семантику для "ключевого несуществующего" , поскольку из чтения вашего определения API выше не ясно. updated: Я вижу, вы добавили метод exists: это необходимо? вы можете использовать метод get и определить a NIL какого-то типа, no?

Возможно, стоит подумать: как насчет того, чтобы "свежесть" значения? т.е. связанная временная метка с последним изменением? Конечно, это зависит от ваших системных требований.

Как насчет контроля доступа? Является ли он в рамках определения API?

Как насчет итерации через клавиши? Если есть возможность большого набора, вы можете захотеть включить семантику pagination.

Ответ 7

При создании API вам нужно спросить себя, что делает мой API для пользователя. Если ваш API настолько упрощен, что для вашего клиента быстрее и проще писать собственное приложение, ваш API не удался. Спросите себя, действительно ли моя функциональность дает им особые преимущества. Если ответ отрицательный, он слишком упрощен и обобщен.

Ответ 8

Как уже упоминалось, чем проще, тем лучше, но простой метод итератора или ключевого листинга может быть полезен. Я всегда нуждаюсь в итерации по множеству. Метод "size()", если итератор не заботится об этом. Это, очевидно, зависит от вашего использования.

Ответ 9

Это не слишком просто, это красиво. Если "exists (key)" является просто удобной стенографией для "get (Key)!= Null", вы должны рассмотреть возможность ее удаления. Я думаю, это зависит от того, насколько велика или сложна ценность, которую вы получаете().