Авторизация и режимы работы с API

Авторизация из локальной сети отеля

Авторизация выполняется от лица пользователя admin – метод авторизации basic.

Документация: http://localhost:5001/api/docs/index.html

Работа выполняется через локальный сервер отеля – задача по администрированию должна решатся системным администратором отеля.

Стандартный путь для обращения к API в локальной сети:

<АДРЕС СЕРВЕРА>/api/<ВЕРСИЯ>/<ЗАПРОС>

Авторизация через облачный интеграционный шлюз

Авторизация выполняется через передачу токена доступа через HTTP заголовок X-Api-Key.

Документация: https://webhub.edelink.ru/integrations/api-docs

Взаимодействие с API выполняется через сеть интернет через облачный сервер по HTTPS.

Предоставление токенов авторизации и подключение отелей выполняется по запросу. Один токен позволяет работать как с одним так и с несколькими отелями.

Стандартный путь для обращения к API через интеграционный шлюз:

 <АДРЕС СЕРВЕРА>/api/gw/{agentId}/<ВЕРСИЯ>/<ЗАПРОС>

Способ возврата ошибок

Для возврата ошибок используется Problem Details – RFC 7807: https://datatracker.ietf.org/doc/html/rfc7807

• Об успехе сообщают двухсотые HTTP коды (200, 201 и т.д.);
• Об ошибках сообщают четырехсотые и пятисотые HTTP коды (400, 401, 404, 500 и т.д.)

Человеко-читаемое сообщение об ошибке можно получить из поля detail.

Часть методов может возвращать дополнительные сведения (например, поле appStatusCode которое позволяет получить машино-читаемый код ошибки).

Способ проверки работоспособности сервера

При работе через облачный шлюз проверить работоспособность сервера можно методом ping (GET или POST)

• Код 200 значит, что интеграционный модуль работает и доступен.
• Код 503 (Service Unavailable) значит, что интеграционный модуль не работает (например, остановлен) .

Пример ответа на запрос, когда сервер доступен: