Авторизация и режимы работы с 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) значит, что интеграционный модуль не работает (например, остановлен) . 

 

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