capi-v2/README.md
Артем d4fe7e16bd
TD-195: Remove old payment methods (#9)
* removed legacy

* fixed format

* fixed

* added some tests, refactored for more coverage

* added requested changes

* fixed dep

* fixed

* fixed

* fixed
2022-04-20 15:07:35 +03:00

51 lines
3.6 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# capi
Сервис предоставляющий третьим сторонам REST API для доступа к нашим системам.
## Сборка
Для запуска процесса сборки достаточно выполнить просто:
make
Чтобы запустить полученную сборку в режиме разработки и получить стандартный [Erlang shell][2], нужно всего лишь:
make start
> _Хозяйке на заметку._ При этом используется стандартный Erlang релиз, собранный при помощи [relx][3] в режиме разработчика.
## Документация
Дальнейшую документацию можно почерпнуть, пройдясь по ссылкам в [соответствующем документе](doc/index.md).
[1]: http://erlang.org/doc/man/shell.html
[2]: https://github.com/erlware/relx
[3]: https://docs.docker.com/machine/install-machine/
[4]: https://github.com/valitydev/feat
## Реализация идемпотентности запросов
Идемпотентность запросов создания/изменения сущностей обеспечивается специальной [подсистемой][4],
которая оперирует несколькими понятиями:
- 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` в тестовые зависимости, когда сборщик сможет качать тестовые зависимости