Несколько замечаний относительно Open Digital API

frameworx9 декабря этого года TMForum опубликовал пресс-релиз о выходе первого Digital Service Toolkit, предназначенного для организации взаимодействия между абонентами и компаниями (операторами и поставщиками услуг) для построения цифровых сервисов и поддержки интернета вещей (Internet of Things). Toolkit представляет собой набор руководств по построению партнерских продуктов и услуг, шаблоны построения бизнес-моделей и организации операционного взаимодействия и спецификации программных интерфейсов. Наверное, наиболее интересно выглядят именно рекомендации по построению бизнес-моделей, собранные в руководстве Online B2B2X Partnering Step by Step Guide, включающем набор готовых шаблонов и примеров, по  разработке ценностного предложения (Customer Market Proposition), бизнес-модели, контрактов на совместное предоставления услуги, финансовой и операционной модели. Но мы поговорим о другом: эталонных архитектурах, моделях данных и спецификациях программных интерфейсов.

Написанием спецификаций программных интерфейсов (APIs) TMForum занимается не первый год. Сначала это выглядело как-то не очень убедительно. Так, например, Simple Management API, предназначенный для управления услугами, вышел в двух версиях – REST XML и REST JSON. Но более поздние спецификации постепенно избавляются от детских болезней, обрастают описаниями моделей предметной области и руководствами для бизнес-заказчиков с веселыми картинками, типа приведенной ниже:

mgmtapi

Но мы обратимся к более конкретным вещам, к устройству APIs. Сейчас разработаны 12 спецификаций интерфейсов:

  • Product ordering API
  • Catalog management API
  • Trouble ticketing API
  • Service level agreement API
  • Performance management API
  • Customer management API
  • Party management API
  • Usage API
  • Billing API
  • Product Inventory API
  • Service Inventory API
  • Resource Inventory API

и большинство из них сделаны в новой логике, которую можно было бы назвать «логикой микросервисов». Последние пару лет все сообщество разработчиков ПО увлечено идеей микросервисов. Мартин Фаулер  не только успевает критиковать идеи SEMAT (см. статью в PCWeek «Анти-SEMAT или каждому свое?«), но и рассказывать нам что же такое микросервисы.  Но, пожалуй, доходчивой всего эту next big thing, а заодно и про CQRS и Event sourcing рассказывают гартнеровские аналитики в своих вебинарах. Картинка с одного из последних

microservices

Рассмотрим, как идеи этой картинки воплощаются в конкретном API, например в Trouble ticketing (можно было взять и Product ordering или другие интрефейсы, все они сделаны по общим принципам, описанным в книжках REST API Design Guidelines TMF630, TMF631).

Query интерфейс выглядит традиционно. Вызовы:

GET /api/ticket

GET /api/ticket?status=Close&statusResolutionDate.gt=2013-05-01

GET /api/ticket/1

GET /api/ticket/1/status,statusChangeReason

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

POST /api/ticket

PUT /api/ticket/1

PATCH /api/ticket/1

И, пожалуй, самое интересное – интерфейсы нотификации. Регистрация интерфейс для получения нотификаций выглядит примерно так

REQUEST

POST /api/hub

Accept: application/json

{«callback»: «http://in.listener.com»}

RESPONSE

201

Content-Type: application/json

Location: /api/hub/42

{«id»:»42″,»callback»:»http://in.listener.com»,»query»:null}

После данного вызова реализующий сервис узел начнет посылать нотификации по указанному адресу

POST /client/listener

Accept: application/json

{

«event»: {

EVENT BODY

},

«eventType»: «eventType»

}

Для завершения отправки нотификаций вызываем

DELETE /api/hub/{id}

В общем, выглядит это все довольно современно, совсем не похоже на эксплуатируемые сейчас в телекомах биллинги, CRM и прочие информационные системы поддержки бизнеса. Впрочем, многочисленные сотрудники отечественных операторов связи и компаний предоставляющих дополнительные сервисы вряд ли читают материалы TMForum. И потому еще много лет будут внедрять морально устаревшие решения 90-х, любезно продаваемые им мегавендорами.

Реклама

10 responses to “Несколько замечаний относительно Open Digital API

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s