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

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

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

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

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

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

источник

2009-07-13 eran

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

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

источник

2009-07-13 11:34:02

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

Но

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

источник

2009-07-13 11:51:02

Мы предоставляем CMS. Наши пользователи создадут свой собственный веб-интерфейс, используя наше приложение через WS API. В большинстве случаев API действительно повлияет на отзывчивость пользовательского интерфейса. Я знаю, что в некоторых случаях детали диктуют решение, поэтому я ищу стратегию для случаев, когда возможны оба пути. – eran

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

источник

2009-07-13 12:02:26

@Dave Anderson: эффективность и простота использования связаны. См. ISO 9241-11. Его все удобство. – Forer

@ForerMedia Я, вероятно, должен был использовать слово «исполнение», а не «эффективность», но использовал его так, как это было в исходном посте. Разумеется, внутренний механизм может быть неэффективным, но простым в использовании или эффективным и сложным в использовании. Интересный пример: ISO 9241-11: 1998 Эргономические требования к офисной работе с терминалами визуального отображения (VDT). Руководство по удобству использования; o) –

@Dave Anderson: связь между эффективностью и простотой использования может быть связана во время использования. если пользователь использует интерфейс один раз, они не понимают, насколько они неэффективны, если раньше они не испытывали пользовательский интерфейс или аналогичный интерфейс. Но, когда пользователь осознает неэффективность системы, они не будут думать, что он предлагает простоту использования, поскольку для достижения желаемого результата потребуется слишком много времени или потребуется повторить задачу, чтобы получить результат. – Forer

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

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

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

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

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

Еще один хороший совет - спросить вас, пожалуйста, перед вами &, как вы идете.

источник

2009-07-13 13:56:41 Forer

Задавая несколько абстрактных вопросов, требующих отчасти абстрактных ответов, поэтому я немного сломаю их: рассмотрим случай одной функции, выполняющей запрос, а другую, которая получает ряд результатов. Если первые возвращают первый набор результатов, а не только число результатов, то это устраняет необходимость в одном вызове последнего. Однако каждая функция принимает разные аргументы и возвращает разные значения. Объединение их будет обеспечивать более быстрый API с комбинированными вызовами, что будет гораздо менее полезным. Будет ли ваш ответ применяться и к C++ API? – eran

Я бы применил свой ответ на любую технологию. Информация о разбивке поможет вам. Поэтому рассмотрим следующее: Вариант 1 - простой API: вызовы API с меньшими наборами параметров (быстрая и простая для пользователя), обеспечивающая дискретную обратную связь. Простой ввод и четкая обратная связь. Частая успешная обратная связь более полезная. Звучит довольно легко с точки зрения пользователя, но может потребоваться время для работы с различными требуемыми вызовами. Вариант 2 - сложный API: вызовы с большими наборами параметров (пользователю потребуется много времени, чтобы указать параметры и правильно) для получения комплексной обратной связи. Звучит сложнее = больше ошибок? – Forer

Вопрос, по-видимому, представляет собой дискуссию по технологии против пользователей. Пользователь должен победить. Так что идите с опцией, которая ставит управление в руки пользователей: одна с более регулярной обратной связью и успешной завершением задачи - ваши пользователи будут иметь более удовлетворительный опыт с меньшим количеством возможных ошибок - представьте себе сложный вызов API, при этом многие пользовательские параметры будут ошибочными. Пользователь будет тратить время, пытаясь понять требования API больше, чем добиваться выхода. – Forer

Мои 2 цента:

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

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

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

источник

2009-07-14 14:19:37 Modicom

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

ответ

Смежные вопросы