Выбор между производительностью и простотой использования в WS API

Question

Мы находимся в процессе создания нового API для нашего продукта, который будет доступен через веб-сервисы. У нас есть внутренняя дискуссия о том, должен ли API быть максимально простым в использовании (за счет увеличения количества вызовов) или сделать его максимально эффективным (усложняя его использование). Например, вот две проблемы, которые возникли:

• Должны ли мы управлять информацией о сеансе на сервере или мы должны передать эту информацию пользователю и ожидать, что он отправит ее нам при необходимости? (Пожалуйста, игнорируйте последствия сеанса для безопасности)
• Должны ли мы объединять вызовы, которые могут быть последовательными, чтобы сэкономить время, затрачиваемое на передачу туда и обратно, даже если они на самом деле не имеют одинаковую логическую функциональность?

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

Лично я за то, чтобы сделать API максимально удобным для использования. Другие компоненты системы, вероятно, будут оказывать гораздо большее влияние на производительность, а сложные в использовании API-интерфейсы гораздо более подвержены ошибкам. Но я программист на рабочем столе ...

Итак, какой должна быть наша стратегия? Каковы общие практики при создании такого API?

Answer 1

Каковы типичные сценарии использования? Будет ли задержка вашего API определять отзывчивость интерфейса? Насколько большой компромисс производительности будет? Трудно что-то предложить, не зная ваших обстоятельств.

Но

1. Я предполагаю, что передача информации о сеансе клиенту будет лучше масштабироваться. Внутрипроцессное управление сеансами не позволит вам совместно использовать состояние между экземплярами службы. Управление сессиями в БД сделает ваши услуги более сложными. В любом случае все зависит от вашей пропускной способности / памяти / вычислительной мощности.

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

Answer 2

Мои 2 цента:

Сначала начните с очень детального низкоуровневого API, который обеспечивает высокую производительность. Затем создайте простой в использовании API высокого уровня, который «составлен» из вышеуказанного API низкого уровня.

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

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

Answer 3

Вы обсуждаете круговой инструмент. Это все удобство использования (простота использования).

Вероятно, вы собираетесь учитывать оба аспекта, поскольку они оба влияют на производительность пользователя.

Это случай (i) степени таможенных признаков и (ii) эффективности манипулирования этими функциями. Между ними будет пересечение.

Я бы сказал, дать простой API, который передает контроль в руки пользователей - это основная цель CMS. Более подробные аспекты, которые вы могли бы объединить вначале, представив их как дополнительный элемент управления позже.

Таким образом, вы будете управлять кривой обучения пользователей системы, чтобы (i) не подвергать их чрезмерным вариантам изначально и (ii) позволить им быстро освоить вашу систему. Затем расширьте контроль пользователей (функциональность системы с точки зрения пользователя), сделав доступными дополнительные функции API.

Еще один хороший совет - спрашивать пользователей заранее и по ходу дела.

Answer 4

Я бы порекомендовал вам создать свой веб-сервис, следуя RESTful модели , и это означает отсутствие состояния. Эффективность важнее, чем простота использования. Позже вы всегда можете создать фреймворк поверх API, который облегчит проблемы с реализацией.

Answer 5

IMO, лучше всего иметь простейший API для людей, которым придется использовать ваш API, но позволяя этим людям иметь широкие возможности настройки, чтобы сделать его эффективным, даже если его сложнее использовать.

Но простота для пользователей> все.