Метка: API

Клиентский опыт и архитектурный стиль RESTful

Разговоры о Customer Experience (опыте клиентского взаимодействия) ведутся уже так долго, что вряд ли способны привлечь чьё-либо внимание. Особенно внимание айтишников. Мол, это вообще не к нам. Есть специально обученные люди – дизайнеры, которые всё сделают правильно и непременно улучшат этот самый клиентский опыт. Архитектурный стиль RESTful, описанный Роем Филдингом аж в 2000 году в диссертации Architectural Styles and the Design of Network-based Software Architectures, привлечет не большие внимание тех же самых айтишников. Всё  ведь и так понятно. JSON поверх HTTP  — вот и весь RESTful. Давайте все же разберемся, о чем этот архитектурный стиль и как он связан с опытом клиентского взаимодействия. Continue reading «Клиентский опыт и архитектурный стиль RESTful»

Брокеры программных интерфейсов (ссылки)

api-iconУ целевой рекламы есть свои неоспоримые преимущества. Если раньше надо было днями выискивать в Интернет действительно интересный ресурс по теме, то теперь достаточно погуглить разок другой и потом тебя начинают засыпать соответствующими рекламными предложениями во всех социальных сетях. На меня в последние дни обрушился поток рекламы самых разнообразных брокеров программных интерфейсов – решений, позволяющих компаниям вытащить свои кривые и убогие APIs в Интернет и выглядеть там не хуже, чем Amazon Web Services. Ну, или не сильно хуже.  Continue reading «Брокеры программных интерфейсов (ссылки)»

Как сделать хороший API?

ArchimateAbstractВ предыдущем сообщении Event-driven architecture я позволил себе заметить, что сервисная шина (ESB) не является необходимым условием построения сервис-ориентированной архитекутры(SOA). О том, что сервисы должны предоставляться именно приложениями много говорят в SOA School Томаса Эрла, используя термин Intrinsic interoperability На занятиях мы довольно долго пытались его корректно перевести и, по-моему, остановились на «врожденной способностью к взаимодействию». Этот принцип, кстати, вошел в СОА-манифест в формулировке «Intrinsic interoperability over custom integration»
Одним словом, речь идет о том, что задача предоставления [ре]юзабильных повторно-используемых программных интерфейсов отводится именно бизнес-приложениям, а не интеграционной среде. (Под юзабилити я понимаю именно юзабилити, а не эргономику. Чем отличается одно от другого см. Юзабилити глазами архитектора)
Вопрос в том, как такие интерфейсы построить.

Вариант 1. Обнаружить стандарт, описывающий данную предметную область (домен). Я не говорю о стандартах вида WS-* они описывают совершенно другие вещи. Речь идет именно о стандартах CMIS, OSS/J и пр.
Вариант 2. Если стандартов нет, и все знания о предметной области локализованы в головах нескольких посвященных соответствующего тайного ордена, то интерфейс придется разрабатывать. И обычно это делается неправильно. Разработчик системы спрашивает, какие данные вам нужны и предоставляет что-то похожее на то, что вы попросили. В результате получаются хранимые процедуры типа:

СуммВырчкНаУтроGF-ЧудесСтрДураков(Кол-воЗолотых)

О повторном использовании таких сервисов говорить, разумеется, не приходится. Очевидный способ построения повторно-используемых интерфейсов – абстрагирование. Про абстрагирование сказано практически во всех работах по программной инженерии от «Программисткого камня» (рекомендую прочитать эту книжку целиком) до классических работ Г.Буча «Объектно-ориентированный анализ и проектирование», но сказано как-то не очень внятно. Поэтому, вопрос как построить хорошую объектную модель, а значит и reusable API остается открытым. Я тоже не знаю полного ответа на этот вопрос, но готов поделиться некоторыми частными, глубоко субъективными наблюдениями:

  • REST лучше чем SOAP, так как оперирует с данными, а не с поведением, а это всегда проще.
  • Референсные модели предметной области, по крайней мере такие, в которых нормальный человек может разобраться, имеют право на жизнь.
  • Что-то чуть более конкретное, чем «Object-Relations» (см. рисунок, предложенный разработчиками ArchiMate).
  • Семь плюс-минус две сущности. Для того, чтоб понять что такое, например WordPress, достаточно посмотреть на структуру его базы данных. В системах, написанных за деньги и на заказ разобраться в структуре данных практически нереально.
  • Классы предметной области и отношения между ними не должны присутствовать в сигнатурах методов. Они должны вести в справочниках, доступных через тот же самый API. Тогда интерфейс становится самоописанным.

Буду признателен за более внятные мысли на тему построения повторно-используемых интерфейсов.