Как вы генерируете ссылки HATEOAS в распределенных архитектурах сервиса REST? - PullRequest
Новая
       8

Как вы генерируете ссылки HATEOAS в распределенных архитектурах сервиса REST?

0 голосов
/ 27 сентября 2018

Я новичок в REST и сейчас провожу много исследований, чтобы рассмотреть вопрос о переносе внутренней монолитной архитектуры сервиса на что-то более простое и более распределенное.У меня возникли некоторые проблемы, связанные с созданием ссылок HATEOAS для ресурсов в распределенной микросервисной системе.Я в целом понимаю, почему вы не должны хранить сами отношения в базе данных, но альтернативой является их генерация в коде.

Если одним из основных преимуществ микросервисов является то, что они позволяют отдельным командам работать независимо друг от друга, чтобыулучшить свои сервисы и API, как одна команда может надежно генерировать ссылки на сервисные ресурсы другой команды?Является ли это просто вопросом отслеживания изменений в ваших API и последующего их правильного управления версиями, чтобы другие группы могли обновлять свои ссылки на ресурсы в любое время?

Если да, то действительно ли лучше просто жестко кодировать ссылки?Мне кажется, что должна быть какая-то лучшая практика для того, как это сделать, я достаточно новичок в сцене, чтобы не найти правильные условия поиска.

Спасибо за любую помощь!

1 Ответ

0 голосов
/ 28 сентября 2018

У меня не было возможности реализовать REST API с использованием HATEOAS, но у меня было время подумать о том, как бы я это реализовал.

Самый интересный способ, о котором я подумал, - это реализоватьсвоего рода «DNS-сервер» для API-интерфейсов REST, который в основном будет создавать URL-адреса для различных API-интерфейсов REST, доступных в вашей системе.

Эта служба типа «DNS» будет предоставлять такую ​​операцию, как:

GET / apis / {resourceTypeIdentifier} / {resourceIdentifier}

, который, в свою очередь, возвращает URL-адрес, по которому ресурс может быть использован.

Пример:

Ваш API (скажем, API предложения) должен вернуть ссылку на ресурс, который находится за пределами его домена (скажем, клиент с идентификатором 001).Чтобы получить ссылку на внешний ресурс, он будет вызывать API-интерфейс DNS следующим образом:

GET / apis / offer / 001

, который будет возвращать URL-адрес, откуда кто-то может получить остальныеинформация об этом ресурсе (например, https://www.example.org/myofferapi/v3/offers/001 или https://www.example.org/myofferapi/v3/offers?offerId=001). Служба может вернуть URL-адрес настолько сложным, насколько это необходимо, если API этого DNS реализован в общем виде.

В этом случае владельцы API будут обязаны обновлять базу данных «DNS» информацией, которая необходима API «DNS» для построения URL-адресов. Это будет нести ответственность за отслеживание и обновление URL-адреса на каждом из них.потребителей и вместо этого положить его исключительно на поставщика услуг.

...