YG
В какой момент мы скатимся к какому-нибудь json-rpc
Size: a a a
2021 August 03
SP
Я с позиции человека которому потом ui под это делать рассуждаю
SP
В этом нет ничего плохого
YG
Ну еще нужно подумать как это расширяться будет, верно?
YG
Тогда какой смысл в url-ах вообще?)
SP
Странички в браузер отдавать, http кэш, все то что тебе не особо интересно
V
url просто signup, либо если совершенно разные сценарии может дополнительные endpoint signup/team. А все остальное в параметрах.
YG
Мне кажется для клиента проще если есть правило: один url - одни правила аутентификации.
Поэтому фронтендера может смутить, что в зависимости от параметра в body - могут менять правила аутентификации.
К тому же в openapi/swagger - это не опишешь
Поэтому фронтендера может смутить, что в зависимости от параметра в body - могут менять правила аутентификации.
К тому же в openapi/swagger - это не опишешь
SP
Не путаешь ли ты аутентификацию и авторизацию?
YG
Нет, первая регистрация - не требует аутентифицированного пользователя. Второе требует, ибо это регистрация дочернего акка
N
понял, спасибо, просто сейчас большинство методов выглядит очень тупо в виде:
function someMethodName(param1, param2) {
serviceInDomain.doSomeMethod(param1, param2)
}
(функция потом маппится на RPC метод "someMethodName" например)
и думал что как то это тупо выглядит
function someMethodName(param1, param2) {
serviceInDomain.doSomeMethod(param1, param2)
}
(функция потом маппится на RPC метод "someMethodName" например)
и думал что как то это тупо выглядит
SP
Ну ок, разные механизмы аутентификации действительно удобнее разруливать урлами
DK
вообще иногда думается мне... всякое чтение и поиск сделать через rest, а остальное через какой нить rpc пустить
SP
Хотя по факту это больше про удобства описания контрактов
SP
А чем этот "рест" с чтением помогает? Вон graphql прекрасно с чтением справляется
YG
А email/phone/… + as-team/as-company/…
задают разные поля при регистрации
что тоже по сути удобно, когда разные урлы - верно?
задают разные поля при регистрации
что тоже по сути удобно, когда разные урлы - верно?
SP
Мне тело надо собрать валидное и так, а ты хочешь что бы я и урл собирал
SP
Ну тоесть с точки зрения контрактов allOf и прочие oneOf решают проблему
DK
ты же сам выше сказал... кэш есть "родной"...