OS
Одна из систем должна быть Source of Truth
Size: a a a
2019 August 26
RT
Одна из систем должна быть Source of Truth
👍
KG
Для голосования бч можно было бы ещё использовать
это вы как пришли к такому пониманию??
RT
Rest корректно реализуется только для внутренних идентификаторов сервиса предоставлчющего апи, идентификаторы внешних систем могут быть лишь синонимами
KI
Rest корректно реализуется только для внутренних идентификаторов сервиса предоставлчющего апи, идентификаторы внешних систем могут быть лишь синонимами
Угу, вот вопрос, как их лучше изобразить снаружи системы.
RT
При этом можно реализовать метод 'поиск сушностей по идентификатору внешней системы'
OS
Угу, вот вопрос, как их лучше изобразить снаружи системы.
Если из варианта 3 сделать не "нарушение стандарта" на одном ендпойнте, а пачку независимых ендпойнтов, то проблем особых не вижу.
AТ
Если из варианта 3 сделать не "нарушение стандарта" на одном ендпойнте, а пачку независимых ендпойнтов, то проблем особых не вижу.
Тоже так кажется. Плюс есть ещё возможный вариант - это разные gateway для разных подсистем. Возможно там и набор методов немного разный будет.
KI
Если из варианта 3 сделать не "нарушение стандарта" на одном ендпойнте, а пачку независимых ендпойнтов, то проблем особых не вижу.
Спасибо. Мысль ясна. Если имеем просто вторичные идентификаторы, то вариант 1 лучше. Если объекты разнятся, хоть и относятся к одному и тому же, то да, разные эндпоинты лучший вариант.
SB
Есть чисто технический архитектурный вопрос. Мне интересно мнение большинства.
Контекст такой: есть ресурс в системе, который имеет несколько уникальных идентификаторов разного вида. Как правильнее описать REST интерфейс к нему?
Предположительно есть такие варианты:
1. Разбить получение объекта на два запроса:
первый - получить основной идентфикатор: /resources/ids?id-type={idType}&id-value={idValue}
основной идентификатор можно назначить из перечня всех
второй - получить по основному - ресурс: /resources/{id}
2. Сделать сложный ключ, из типа и значения идентификатора:
/resources/{idType}:{idValue}
3. Отойти от стандарта и явно включить тип идентификатора в контракт: /resources/{idType}/{idValue}
Контекст такой: есть ресурс в системе, который имеет несколько уникальных идентификаторов разного вида. Как правильнее описать REST интерфейс к нему?
Предположительно есть такие варианты:
1. Разбить получение объекта на два запроса:
первый - получить основной идентфикатор: /resources/ids?id-type={idType}&id-value={idValue}
основной идентификатор можно назначить из перечня всех
второй - получить по основному - ресурс: /resources/{id}
2. Сделать сложный ключ, из типа и значения идентификатора:
/resources/{idType}:{idValue}
3. Отойти от стандарта и явно включить тип идентификатора в контракт: /resources/{idType}/{idValue}
Сделать еще один, внутренний id, и поддерживать маппинг на внешние id-шники? Вообще, наличие "внутреннего" и "внешнего" айдишника - довольно частый подход даже в простых ситуациях, к примеру, uuid выставляется наружу, а в РСУБД - автоикремент.
KI
Сделать еще один, внутренний id, и поддерживать маппинг на внешние id-шники? Вообще, наличие "внутреннего" и "внешнего" айдишника - довольно частый подход даже в простых ситуациях, к примеру, uuid выставляется наружу, а в РСУБД - автоикремент.
Ну это тянет на вариант 1. Я, в общем то, сам к нему сколнен. Просто интересны мнения )
AТ
Сделать еще один, внутренний id, и поддерживать маппинг на внешние id-шники? Вообще, наличие "внутреннего" и "внешнего" айдишника - довольно частый подход даже в простых ситуациях, к примеру, uuid выставляется наружу, а в РСУБД - автоикремент.
Я так понял там два разных идентификатора с двух разных подсистем у одной сущности. И не всегда, видимо, можно назвать кто 'первее'?
OS
По мне, немного копипасты лучше протёкшей абстракции, поэтому когда можно разделять - я бы делил
SB
Ну это тянет на вариант 1. Я, в общем то, сам к нему сколнен. Просто интересны мнения )
Я голосовалку не вижу с компьютера, увы.
OS
IdType я бы назвал схемой
OS
Тогда будет взаимно однозначно - подсистема, схема, ендпойнт, тип id
KI
Тогда будет взаимно однозначно - подсистема, схема, ендпойнт, тип id
Логика в этом определенно есть.
OS
Будет шанс потом ендпойнты по микросервисам раскидать, или независимо их депрекейтить, в случае отказа от подсистем или их эволюции
AТ
У нас была похожая задача немного, где в систему вставлялись данные с двух источников для сравнения. Каждая сторона могла (но не обязана) прислать свой и внешний идентификатор. В итоге получали варианты, где оба участника присылали оба идентификатора (выбирай любой), когда у них было пересечение только по одному.
Потом, конечно же, добавились ситуации, где с обоих сторон приходили данные, которые приходилось мапить не по идентификаторам, а чему нибудь ещё.
Потом, конечно же, добавились ситуации, где с обоих сторон приходили данные, которые приходилось мапить не по идентификаторам, а чему нибудь ещё.
AТ
Я к чему это все. У сервиса должен быть нормальный контракт: id/ external_id, все что выходит за рамки этого - это по сути вставляется через адаптеры.