capi

Сервис предоставляющий третьим сторонам REST API для доступа к нашим системам.

Сборка

Для запуска процесса сборки достаточно выполнить просто:

make

Чтобы запустить полученную сборку в режиме разработки и получить стандартный Erlang shell, нужно всего лишь:

make start

Хозяйке на заметку. При этом используется стандартный Erlang релиз, собранный при помощи relx в режиме разработчика.

Документация

Дальнейшую документацию можно почерпнуть, пройдясь по ссылкам в соответствующем документе.

Реализация идемпотентности запросов

Идемпотентность запросов создания/изменения сущностей обеспечивается специальной подсистемой, которая оперирует несколькими понятиями:

• ExternalId - внешний идентификатор сущности.
• Features - значимая часть данных запроса, изменение которых может появлиять на результат выполнения запроса.
• Schema - рецепт как из полной структуры данных запроса получить Features.

В случае, когда в запросе фигурирует ExternalId, сервис будет обрабатывать запрос идемпотентно. Для структуры данных запроса существует Schema, по которой извлекается Features. Features ассоциируется с переданным ExternalId. При повторе запроса с таким же ExternalId код извлечет Features из новых данных и сравнит их с Features оригинального запроса, в случае совпадения сервис ответит идемпотентно, в противном случае сервис ответит ошибкой с кодом 409.

TODO

• Вернуть передачу в hellgate контрактора, сразу как только там появятся интерфейс и бизнес-логика управления договорами
• Ленивое создание мерчанта
• Error Mapping
• CORS (текущая версия не знает об операциях и авторизации, что в общем случае неприемлемо)
• Тотальное логирование
• При разбиению по месяцу в запросах статистики ответ приходит с разбиением по 30 дням, что не очевидно
• В сгенеренном swagger коде в handle_request_json следует учесть, что ответ вида {false, Req1, State} невалиден и приводит к 500 ошибке
• Перевести capi_mock_handler на thrift-чучела
• Убрать cowlib в тестовые зависимости, когда сборщик сможет качать тестовые зависимости