ммм.... скажу так. Вот то с чем я сейчас работаю - это типа сильно хуже того что у меня обычно)

большой объём для рефакторинга ?

а какие-то неочевидные плюсы есть?

никаких

никаких

херово

мы вот щас хотим собрать все текущее мясо, и привести его в порядок. но проблема в том что часто одна и та же сущность в разных местах может быть по-разному представлена. где-то нужны картинки-логотипы, где-то детальная инфа, где-то еще какая-то ебала

мы вот щас хотим собрать все текущее мясо, и привести его в порядок. но проблема в том что часто одна и та же сущность в разных местах может быть по-разному представлена. где-то нужны картинки-логотипы, где-то детальная инфа, где-то еще какая-то ебала

ну разные представления - разные ресурсы

разные урлы

больше кода, зато явно, проще поддерживать, проще с обратной совместимостью

мы вот щас хотим собрать все текущее мясо, и привести его в порядок. но проблема в том что часто одна и та же сущность в разных местах может быть по-разному представлена. где-то нужны картинки-логотипы, где-то детальная инфа, где-то еще какая-то ебала

я помню когда то фракталом пытался такое привести в норму

т.е городить какие-то флажки и подобгие graphql это стрельба по ногам

когда то он почти мне нравился даж(

я помню когда то фракталом пытался такое привести в норму

ну вот у меня на предыдущих проектах был переписанный немного фрактал

т.е городить какие-то флажки и подобгие graphql это стрельба по ногам

нет, подобие graphql (когда у тебя вся инфа о том что ты хочешь получить есть в запросе + все nullable по дефолту) - это хорошо

просто тогда лучше не подобие а graphql

не хочу graphql

?

просто тогда лучше не подобие а graphql

а ещё лучше, когда ещё и фронтовые типы генерятся)

grpc прикольнее да

а ещё лучше, когда ещё и фронтовые типы генерятся)

ну главное что бы контракт можно было загенерить - тогда вообще простор для поддержвания качества

у grpc не очень прикольно с версионностью и шарингом proto файликов

у grpc не очень прикольно с версионностью и шарингом proto файликов

версионность - оч сомнительная фича. честно говоря я не думаю что версионность API это вообще хорошая идея

openapi yaml + генератор, выйдет примерно такой же результат

ну то есть версионность, прикольно... вот только обратную совместимость на пол года-год твоей апишки (если у тебя мобильники или внешние клиенты) это не отменяет

а если у тебя и так обратная совместимость - нафига тебе версии?

у нас попроще, у нас только веб фронт, который может только на неделю отставать от бекенда по версии

у нас попроще, у нас только веб фронт, который может только на неделю отставать от бекенда по версии

тем более версии не нужны))

пока больше проблема со структурами данных

ну пока из моих шишек: - версионность апи это абман - nullable first (из свежих концептов которые я раньше не понимал а сейчас понимаю насколько круто) - все респонсы должны возвращать данные в обертке унифицированной, что бы было проще расширять чуть что. Ну то есть не массивчик или не, упаси сатана, строка, а объектик с полем. - штуки типа graphql хороши когда у тебя примитивные структуры данных. У меня например есть рекурсивные формы, которые ты никогда и никак не опишешь в терминах graphql - разные представления данных должны явно быть прописаны на уровне запроса (разные урлы, заголовки, все что угодно что можно на роутер спихнуть)

простой пример, это все что в карте валяется. где-то нужны способы доставки к тому что там валяется, где-то нужны еще и таксы, а где-то для таксов нужно внешний сервис дергать. и вот пока хз как делать, пока думали чета в духе /cart/1 /cart/1/preview /cart/1/full

ну пока из моих шишек: - версионность апи это абман - nullable first (из свежих концептов которые я раньше не понимал а сейчас понимаю насколько круто) - все респонсы должны возвращать данные в обертке унифицированной, что бы было проще расширять чуть что. Ну то есть не массивчик или не, упаси сатана, строка, а объектик с полем. - штуки типа graphql хороши когда у тебя примитивные структуры данных. У меня например есть рекурсивные формы, которые ты никогда и никак не опишешь в терминах graphql - разные представления данных должны явно быть прописаны на уровне запроса (разные урлы, заголовки, все что угодно что можно на роутер спихнуть)

nullable first это для forward совместимости полезная штука, так то от nullable я б как от огня избавлялся

>- все респонсы должны возвращать данные в обертке унифицированной, что бы было проще расширять чуть что. Ну то есть не массивчик или не, упаси сатана, строка, а объектик с полем. вот тут да. + композиция удобнее чем nullable поля которые хз как заполняются

ну короч, тема сложная, а мне надо работать)

эх, хотел с тебя полезной инфы вытянуть

а ты работать)

эх, хотел с тебя полезной инфы вытянуть

+++

обмажься проекциями и возвращай в зависимости от фазы луны как хочешь)

https://github.com/moby/moby/blob/master/pkg/namesgenerator/names-generator.go#L820

так в докере генерят имя контейнера

хочется сделать не идеальное апи по всем канонам rest, а удобное. на данный момент оно работает, но глаза режет что есть куча похожих структур одного и того же, но в разном представлении. и в документации это будет не оч смотреться

хочется сделать не идеальное апи по всем канонам rest, а удобное. на данный момент оно работает, но глаза режет что есть куча похожих структур одного и того же, но в разном представлении. и в документации это будет не оч смотреться

REST это когда у тебя html, ссылки и формы и сервер полностью управляет переходами между состоянием (потому оно REpresentational State Transfer). Как только у тебя на клиенте хоть что-либо хардкодится (урлы, структуры данных) - у тебя уже не REST. Это не хорошо и не плохо - просто тебе не нужен REST. Тебе нужно JSON RPC

слышу HATEOAS"ом

повеяло

JSON RPC забивает болт на http методы и вообще хоть какую-то семантику

или Unified Interface (одно из семи ограничений реста, что бы "это" можно было называть рестом)

JSON RPC забивает болт на http методы и вообще хоть какую-то семантику

нет, не забивает.

у тебя висит эндпоинт, куда ты шлешь {method: createUser, ...}

ну то есть нет никаких стандартов а потому ты забиваешь а не json rpc)

у тебя висит эндпоинт, куда ты шлешь {method: createUser, ...}

ну расскажи мне про семантику POST и PUT. Что когда юзать?

могу ли я POST для обновления заюзать а PUT для создания?

можно отвечать тем, кому вопрос не адресован?

да, конечно

PUT идемпотентный, POST не очень. а так юзай, в чем проблема)

оба запроса не безопасные

и так или иначе мофицируют ресурс

обычно человеки делают (если делают) put на добавление изменённой версии, а на post всё прочее. ну короче кто на что горазд) именно поэтому у меня в апишках ток гет и пост, ибо нехер)

PUT идемпотентный, POST не очень. а так юзай, в чем проблема)

ты достиг просветления. Теперь я знаю что ты знаешь что делаешь)

оба запроса не безопасные

нет, PUT обязан быть безопасным (идемпотентным)

POST не обязан, потому в целом им можно делать вообще все и это будет ок

безопасный и идемпотентный разные вещи же

просто идемпотентность это круто

и удобно

безопасный и идемпотентный разные вещи же

ну так и GET тогда не безопасный потому что тебе хуйня может придти)

ну так и GET тогда не безопасный потому что тебе хуйня может придти)

я руководствуюсь rfc 2616

там гет безопасный и идемпонетный

руководствуйся чем хочешь - главное что бы апишка была удобной

твоя правда

ты достиг просветления. Теперь я знаю что ты знаешь что делаешь)

ну ты вообще понял о чем я говорил изначально же я к тому что /cart/delete?=1 или /user?approve=1, или когда выборки с post делают, позаменять на более адекватные варианты

ну ты вообще понял о чем я говорил изначально же я к тому что /cart/delete?=1 или /user?approve=1, или когда выборки с post делают, позаменять на более адекватные варианты

ну я понимаю о чем ты, я к тому что для меня что DELETE /cart что POST /cart/delete это все JSON RPC

разница лишь в том что первое удобнее так как я точно знаю что ты гарантируешь мне идемпотентность операции. А во втором случае - надо уже доки читать и расставлять if-ы в коде. что неудобно

а так я на клиенте могу сделать что-то типа... if(['GET', 'PUT', 'DELETE'].includes(request.method)) { return retry(request) }

кстати пример с идемпотентностью делита

я честно спиздил у тебя и на каждом собесе рассказываю ыы

в плане что попытка удалить несуществующий ресурс это не LogicException

а успех)

ну.. там могут быть soft delete и он по факту будет всегда существующим)

ой софт делит это рак вообще(

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

204 возвращай если ниче не сломалось и все)

ну.. там могут быть soft delete и он по факту будет всегда существующим)

я просто на клиенте не хочу обрабатывать ошибку если я хотел удали а уже кто-то удалил. Оно в том состоянии в котором я хотел - значит все хорошо

и да есть исключения

и да есть исключения

можешь привести пример?)

можешь привести пример?)

когда надо явно сказать что кто-то успел удалить

я почему то все равно не могу придумать, в плане если ты что то хочешь удалить, с--цию в которой ты бы проиграл если бы это удалил кто то другой

разве что модераторам каким-то

ну хз, всякие бывают случаи и приходится идти на компромисы)

которым платят за удаление комментария)

которым платят за удаление комментария)

и успешное удаление онного это запись в базу и копеечка

POST /comment/1/delete даже такое в теории может понадобится)

можешь привести пример?)

ну когда не идемпотентно. но тут больше пример @Enleur выше

крч получается почти любой режим гонки

один из моментов - изменение чего-либо можно обыграть как создание события/действия. типа POST /something/{id}/approve

когда удаление ресурса это какой-то профит

ну в целом это все не так критично

хуже когда в GET происходит изменение, тебе возвращают 200, а в резалте есть некий success: false

запросы на чтение через POST фигачат

я один раз видел как умудрились завязаться на порядок отдаваемых элементов

и скатываются вот в такие штуки /get-all-users

ну у нас есть все выше перечисленное)