SG
а, понял, типа закрыть сервис как черный ящик за неким sdk. Ну дизайн api маппится на sdk 1 к 1. Значит надо будет писать документашку на этот sdk и решать все те же проблемы дизайна.
Size: a a a
2021 November 18
AB
Но в пяти соседних кусаках для похожих методов хочешь же похоже поведение? Ну там ретрай, например?
AB
Т.е. не иметь дело с бессмысленным разнообразием
VF
не то что бы надо, его и так почти всегда закрывают, вопрос сколькими способами
PD
Неа. Одинаковые.
API - оно про то, как мы смотрим на домен, какие в нем есть события, как его делим на агрегаты.
Какие есть базовые примитивы событий, какие особенности.
Да, там есть в том числе и вопросы "как обрабатывать ошибки", но это мелочь, как ни странно.
И не требует особых ресурсов, хотя иногда библиотечная поддержка и нужна.
API - оно про то, как мы смотрим на домен, какие в нем есть события, как его делим на агрегаты.
Какие есть базовые примитивы событий, какие особенности.
Да, там есть в том числе и вопросы "как обрабатывать ошибки", но это мелочь, как ни странно.
И не требует особых ресурсов, хотя иногда библиотечная поддержка и нужна.
VF
КОнечно, поэтому над апи почти всегда есть какая-то обертка
PD
А вот аутентификация уже сильно зависит от клиента. Для мобилки, веба и внутри бэка - она разная.
Как и авторизация (
Как и авторизация (
VF
Ну ты можешь для пользователя дать возможность сделать while(req.next()), а внутри можешь сделать что хочешь
SG
логично же, если разработчики будут общаться на одном языке при обсуждении контрактов. Т.е. нужен какой-то idl, например openapi или protobuf.
VF
ну и ее я тоже как клиент не хочу делать, хочу 2 параметра отправить и потом чтобы у меня все работало
PD
Реально, из опыта, общим для всех видов клиентов (внутренние сервисы, внешние сервисы, веб, мобилка) остается только "при http 500 retry не делаем, а при 503 - делаем" и подобные правила.
Все остальное - увы, специфично.
Все остальное - увы, специфично.
PD
А не бывает так, увы (
Аутентификацию нельзя свести к "отправить два параметра".
Аутентификацию нельзя свести к "отправить два параметра".
VF
Разработчик клиента хочет пример кода, который он скопипастит и из этого кода получит данные или их отправит. Как оно там внутри, его вообще не интересует
SG
пример кода != документация
VF
ну ты же как пользователь набираешь логин пароль и пользуешься сервисом, вот погромист тоже так хочет. В худшем случае там будет какой-то токен, которые нужно будет куда-то прокинуть
VF
да кто читает спеки на АПИ сервера, если есть примеры, которые делают то что надо? Хачем? читать приходится только тогда, когда нет готового сценария использования
VF
вот у гугла есть куча возможностей в апи, но попробуй их заиспользуй без библиотеки, это супер непросто, но они еще и не все в библиотеки прокибывают
VF
приходится читать описание апи только когда сделать что-то надо, а библиоткера не поддерживает, пирчем совершенно непонятно почему
SG
намного проще же заглянуть в swagger песочницу, где все эндпоинты структурированы, чем разбираться в коде какой-то локальной клиенской библиотеки
MG
в свагере же даже дают клиента сгенеренного если надо - так что это не пример