у него недоверие к инпуту

....

у тебя аутпут а не инпут

или то что лезет из слоя ниже это у тебя инпут?

ты забавный)

все так говорят

у тебя аутпут а не инпут

всеравно дто )

всеравно дто )

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

да не торопись я на обед

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

тем более что в php нет возможности красиво это хэндлить (делать ссылки на поля классов)

зато есть массивчики (которые не массивчики вовсе))

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

p.s. для запросов DTO как объект определенного типа всеравно удобнее, тут спора нет. Хотя ценность не столь высока как в java. А в PHP все эти пляски с DTO для респонсов вынуждают кодогенераторы писать

ясн )

https://stackoverflow.com/a/6711169 на всякий случай вдруг кому пригодится

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

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

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

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

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

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

выяснение "а нахуй вот это" занимает примерно 80% времени )

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

"приходит", а я про "уходит"

чувствуешь разницу?

направление разница

)))

не чувствуешь, понял

"уходит куда то" против "приходит что то в шаблон" - че разница большая есть?

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

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

это не рассматривал как минус? )

"уходит куда то" против "приходит что то в шаблон" - че разница большая есть?

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

ну то есть сериалайзер тот же

очень узкий кейс, специфичный для апишек и очень даже частый для апишек

а что за место это "где то"

ну вот что там, кто клиент?

а что за место это "где то"

например SPA на реакте

или iOS приложение на swift

между нами - json

что они там уже будут делать, мэпить на DTO через какой-нибудь мэппер, юзать как есть + проверка типов через flow/typescript - на бэкэнд это вообще никак не влияет

а документация к апи откуда берется

а документация к апи откуда берется

а у тебя она откуда берется?

ну т.е. в нормальном апи всегда есть "модели данных" как мне видится

с дто можно нагенерировать

а у тебя? )

с дто можно нагенерировать

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

а у тебя? )

у меня обычно сначала дока и потом имплементация

потому я могу из доки и DTO сгенерить, или рулы валидации отдельные...

ну ок дока и имплементация

а потом когда надо поднять версию

добавить 3-4 поля

а делаешь не ты

а потом когда надо поднять версию

какую версию?

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

другую

ты про заведомо мертвую идею версионизации API?)

версию апи

чем она мертвая? нормальная такая идея

просто уточню - ты пилил API? приходилось заниматься версионированием оной?

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

для долгоиграющих необновляющихся клиентов еще не пилил

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

а ты хуякс на том же хосте начинаешь менять модели данных

тут на помощь спешит версионирование

не?

или как то подругому можна?

мне на эту тему нравится как страйп делают

ERROR: S client not available

обратную совместимость апишек

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

тебе рассказать что я пилю в основном? апишки для мобилок)

но показать не можешь, да?

но показать не можешь, да?

что именно?) мобилки?

исходники?

ага

NDA, сорян

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

у меня обычно сначала дока и потом имплементация

А на чём пишешь доку? Если говорить о человеке уровня джуна который впервые начинает делать апи - стоит ли изначально писать доку и под неё код или лучше наоборот?

так многие не могут

о у тебя то я надеялся хотя бы есть 1-2 для паблика

А на чём пишешь доку? Если говорить о человеке уровня джуна который впервые начинает делать апи - стоит ли изначально писать доку и под неё код или лучше наоборот?

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

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

а так по доке можно заглушек налепить

А на чём пишешь доку? Если говорить о человеке уровня джуна который впервые начинает делать апи - стоит ли изначально писать доку и под неё код или лучше наоборот?

это как тебе удобно. Раньше юзал api blueprint (и до сих пор считаю этот формат крутым), сегодня рекомендую посмотреть в сторону raml (хотя блупринта может и хватить). Мне такой подход (сначала дока) был удобен потому что можно было распаралелить разработку клиента и сервера. Это часто нас спасало.

сейчас больше смотрю в сторону Graphql и подобным способам задавать схему для API но все это пока сыро мутно

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

Ясно, спасибо, ну не уверен что подойдёт так как фронтенд тоже сам собираюсь писать, но наверное надо попробовать, вместо т.з - дока по апи

Ясно, спасибо, ну не уверен что подойдёт так как фронтенд тоже сам собираюсь писать, но наверное надо попробовать, вместо т.з - дока по апи

собирается писать доку для API для тебя? как тз?

пусть пишет в каком-нибудь apiary

есть еще клевые штуки типа swagger 2 typescript

и подобные

Он - это я, невнимательно прочитал наверное, я фуллстаком буду на этом проекте

да... надо отдохнуть)

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

@fes0r ну так и все же что делать с версионированием

@fes0r ну так и все же что делать с версионированием

смотря какое приложение пилишь и как у тебя организована API

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

но наилучшая стратегия - отсутствие версионирования. Дальше вопрос - почему ты не можешь этого делать.

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

добавлять параметры ты то можешь - это не нарушает обратную совместимость

(в респонс, мы пока только про респонс). Хотя даже если про запросы - если ты добавил параметры - логика приложения должна остаться работать потому либо дефолты либо опциональные параметры. По другому никак. В итоге у тебя так или иначен а уровне приложения должна сохраняться обратная совместимость для всех версий твоей API

работал я с такой апишкой однажды, ну и кореша тоже

много модулей напилили