как будешь проверять что password валиден?

и что мы можем поменять пароль?)

в идеале у тебя как-то по этому запросу должен быть вызван метод у сущности User - changePassword($password, $newPassword). ИЛи так уже не выйдет? или нам придется по схеме тела запроса понимать что дергать?

Ну дейсвий будет чуть больше, чем обычный POST /user/updatepass Но зато что мой вариант создания чувака (регистрации) POST /users/ что апдейт пароля PATCH /users/{id} внутри (после контроллера) поедут внутрь одного и того же кода

в идеале у тебя как-то по этому запросу должен быть вызван метод у сущности User - changePassword($password, $newPassword). ИЛи так уже не выйдет? или нам придется по схеме тела запроса понимать что дергать?

Yes - if (present($password && $newPassword) {changePassword($password, $newPassword)} ?

Ну дейсвий будет чуть больше, чем обычный POST /user/updatepass Но зато что мой вариант создания чувака (регистрации) POST /users/ что апдейт пароля PATCH /users/{id} внутри (после контроллера) поедут внутрь одного и того же кода

1. у тебя есть ресурс /users/{id}. 2. у тебя есть 3 операции с одним и тем же http verb для одного ресурса (изменение профайла, изменение пароля, изменение email-а). Отличия только по схеме тела запроса, если по тому что ты предлагаешь делать 3. как мне преобразовать это в разные вызовы методов с разными аргументами для моей доменной модели?

ну то есть маршрутизация действий на основе схемы запроса

Yes - if (present($password && $newPassword) {changePassword($password, $newPassword)} ?

ну это уж совсем ни в какие ворота :)

чем это лучше POST users/{id}/changeEmail, POST users/{id}/changePassword, PUT /profiles/{id}

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

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

как раз об этом

1. в чем профит твоего подхода для клиента? 2. в чем профит твоего подхода для сервера?

если что мне как фронтендеру выгоднее иметь у ресурса 3 разных метода которые принимают на вход разные схемы, нежели 1 метод который принимает anyOf от 3 схем

как бэкэндеру мне это так же выгоднее так как проще организовать маршрутизацию

чем это лучше POST users/{id}/changeEmail, POST users/{id}/changePassword, PUT /profiles/{id}

чет тебе не нравится PUT /users/{id}/password и PUT /users/{id}/email?

чет тебе не нравится PUT /users/{id}/password и PUT /users/{id}/email?

ммм... ну на счет email там PUT хорошо, а вот с паролем - там не идемпотентная операция.

за что битва?... HTTP methods vs URI Path? глупо взрослым людям о таком спорить...

ммм... ну на счет email там PUT хорошо, а вот с паролем - там не идемпотентная операция.

ну там POST мб, да

за что битва?... HTTP methods vs URI Path? глупо взрослым людям о таком спорить...

у человека есть мнение что стоит обмазываться PATCH методом и делать маршрутизацию на основе схемы

ну пусть делает, это же вкусовщина

ну там POST мб, да

ну то есть это уже не важно, там дальше вопрос идемпотентности операции

ну пусть делает, это же вкусовщина

мне может быть потом поддерживать его код)

1. у тебя есть ресурс /users/{id}. 2. у тебя есть 3 операции с одним и тем же http verb для одного ресурса (изменение профайла, изменение пароля, изменение email-а). Отличия только по схеме тела запроса, если по тому что ты предлагаешь делать 3. как мне преобразовать это в разные вызовы методов с разными аргументами для моей доменной модели?

Да, у меня операции 3, а может и 10 для одного юзера. В зависимости от того, что ты передашь в теле - будут посланы емейлы или не будут. Я могу использовать один и тот же запрос для любого изменения, я не буду плодить свои ендпоинты. И код будет один. Если тебе при передаче двух паролей нужно перегенерить хеши - то if это не проблема. Зато у меня код(даже контроллера) прописана один раз. А не 100-500 методов на каждый чих. Клиент в любой момент может добавить поле - и все работает. Тебе же нужно для каждого чиха добавлять новый эндпоинт.

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

Да, у меня операции 3, а может и 10 для одного юзера. В зависимости от того, что ты передашь в теле - будут посланы емейлы или не будут. Я могу использовать один и тот же запрос для любого изменения, я не буду плодить свои ендпоинты. И код будет один. Если тебе при передаче двух паролей нужно перегенерить хеши - то if это не проблема. Зато у меня код(даже контроллера) прописана один раз. А не 100-500 методов на каждый чих. Клиент в любой момент может добавить поле - и все работает. Тебе же нужно для каждого чиха добавлять новый эндпоинт.

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

а если клиент послал undefined, то сменишь емейл?)

как бэкэндеру мне это так же выгоднее так как проще организовать маршрутизацию

Лол у меня один роут. У тебя 3 - кому проще? Для клиента у меня один урл, один запрос - у тебя три... почему три проще одного?

проще 3 роута, потому что роутер уже написан, а тут приходится выдумывать роутер по схеме тела запроса

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

Походу какой-то реальный кейс. Распиши еще раз, чтобы я понял (пока что не понял, что за портянка).

брр

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

проще 3 роута, потому что роутер уже написан, а тут приходится выдумывать роутер по схеме тела запроса

ну лол.... какие три роута.

Лол у меня один роут. У тебя 3 - кому проще? Для клиента у меня один урл, один запрос - у тебя три... почему три проще одного?

мне проще) потому что нет if-ов

Походу какой-то реальный кейс. Распиши еще раз, чтобы я понял (пока что не понял, что за портянка).

два действия: 1. смена пароля 2. смена email Для смены пароля в теле запроса должны приходить старый пароль, новый пароль и емейл Для смены емейла надо отправлять пароль и новый емейл

Ну если чего-то не хватает, чтобы операция прошла успешно за один API call то ничего не произойдет.

ситуация: на клиенте багуля и вместо нового пароля посылается undefined, ты меняешь email?

ситуация: на клиенте багуля и вместо нового пароля посылается undefined, ты меняешь email?

кинет ошибку и не даст тебе сделать оба действия)

короч это какой-то CRUD way для работы с данными

кинет ошибку и не даст тебе сделать оба действия)

а какую, по-хорошему должен сказать, что схеме не соответствует, но как он это поймет?

мне проще) потому что нет if-ов

а нельзя совмещать? т.е. какие то стандартные данные меняются в обычно patch а для чего то со своей доп логикой (смена статуса, пароля и т.п.) уже отдельные ендпоинты? и насколько некорректно будет patch метод (а не пост) на таких ендпоинтах?

а какую, по-хорошему должен сказать, что схеме не соответствует, но как он это поймет?

какой из схем запрос должен соответствовать?)

мне больше прельщает мысль что у каждого ресурса своя недвусмысленная определенная схема. С path так не выйдет. либо это будет массив операций.

а нельзя совмещать? т.е. какие то стандартные данные меняются в обычно patch а для чего то со своей доп логикой (смена статуса, пароля и т.п.) уже отдельные ендпоинты? и насколько некорректно будет patch метод (а не пост) на таких ендпоинтах?

можно, конечно, но зачем тебе PATCH?

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

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PATCH

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

я с этим сталкивался) правда не для PATCH а для POST запросов... это та еще боль

ЭЭЭЭЭЭ дисертация чувака философа за 2000г ..... сча бы в 2017 это читать. Мне не интересно откуда rest термин - я вижу рекомендации, которые, пока что, решают мои проблемы. http://www.restapitutorial.com/lessons/httpmethods.html Эти рекомендации называют RESTful (я встречал такое определение). Повторюсь, вещь не описывает все кейсы, но между вариантом писать POST /user/sendemail (и т.п. говно) и вот этим "RESTful" я выбираю второе.

вообще это звучит "слышу звон...", типа что-то кто-то написал, ну чо, выглядит симпатично, а, гавное, модерново... ;) Все же стоит разобраться о том, что такое REST, ибо вообще-то сначала был REST, а потом HTTP/1.1 :)

короч это какой-то CRUD way для работы с данными

Ес.

Ес.

ну тогда нам с тобой не по пути)

а какую, по-хорошему должен сказать, что схеме не соответствует, но как он это поймет?

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

не, если нравится, то почему бы и нет... но, блин... не аксиома совсем

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

а почему ошибка, все данные переданы

только не для того запроса, который хотелось

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

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

Нету никакого роутинга. Есть бизнесстребования "Если хочешь новый пароль, передай старый" if (newPass){checkOld} Это Все, никаких маршрутов. Это бизнесстребования.

можно, конечно, но зачем тебе PATCH?

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

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

вот ты просто мне скажи - зачем так усложнять когда можно просто 3 роута сделать. это ж проще. Проще объяснять как взаимодействовать. Проще разруливать ситуации разные.

почему ты считаешь что это "хорошо"?

Нету никакого роутинга. Есть бизнесстребования "Если хочешь новый пароль, передай старый" if (newPass){checkOld} Это Все, никаких маршрутов. Это бизнесстребования.

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

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

по сути нам надо выполнить операцию а не патч применить. Да и "описание изменений" штука намного сложнее нежели кусок стэйта.

только не для того запроса, который хотелось

Ну так проблемы пролетарии буржуазию не парят. Я напишу, что тебе не хватает филда. (А если ты сунешь дополнительные поля, которых ты не хотел всунуть то это твои проблемы (клиента))

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

Баланс как обычное поле user? Или транзакция?

Ну так проблемы пролетарии буржуазию не парят. Я напишу, что тебе не хватает филда. (А если ты сунешь дополнительные поля, которых ты не хотел всунуть то это твои проблемы (клиента))

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

Если транзакции, то это отдельный ресурс.

Ну так проблемы пролетарии буржуазию не парят. Я напишу, что тебе не хватает филда. (А если ты сунешь дополнительные поля, которых ты не хотел всунуть то это твои проблемы (клиента))

http://www.makak.ru/wp-content/uploads/2012/11/G97LnYT1rjs.jpg

Баланс как обычное поле user? Или транзакция?

как обычное поле, ну пускай не баланс, а адрес

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

Я не имеею ввиду ничего. Я пишу код. Если пришел новый емейл - смотрим можем ли мы его обновить. В твоем кейсе нет, нужно еще пароль. Если бизнесстребования такого нету, то просто обновляем модель. Если вс ебизнесстребования выполнены то $em->flush()

Я не имеею ввиду ничего. Я пишу код. Если пришел новый емейл - смотрим можем ли мы его обновить. В твоем кейсе нет, нужно еще пароль. Если бизнесстребования такого нету, то просто обновляем модель. Если вс ебизнесстребования выполнены то $em->flush()

а я имею) Еще раз для смены пароля нужны три поля: старый пароль, новый пароль и емейл. Для смены мейла два поля: пароль и емейл. Как ты отличаешь, что забыли указать новый пароль и кидаешь ошибку от запроса на смену емейла?

нету роутов, я не проксирую реквесты в другие контролеры или другие сервисы. Я делаю бизнесслогику. Если тебе нужны проверки на какие-то поля - ставь. Не нужны - не ставь. В чем проблема. Way действительно CRUD но вайнот?

а я имею) Еще раз для смены пароля нужны три поля: старый пароль, новый пароль и емейл. Для смены мейла два поля: пароль и емейл. Как ты отличаешь, что забыли указать новый пароль и кидаешь ошибку от запроса на смену емейла?

Что пришло в запросе? Ты только требования указал

Сча отвечу.

нету роутов, я не проксирую реквесты в другие контролеры или другие сервисы. Я делаю бизнесслогику. Если тебе нужны проверки на какие-то поля - ставь. Не нужны - не ставь. В чем проблема. Way действительно CRUD но вайнот?

бизнес логику в контроллерах, попрошу заметить)

бизнес логику в контроллерах, попрошу заметить)

НОУ

ситуация: на клиенте багуля и вместо нового пароля посылается undefined, ты меняешь email?

НОУ

а где ты принимаешь решение о том что надо сделать?)

мне вот интересно - ты реально юзаешь PATCH так как описал?)

я поверю только если в целом от API нужен тупой CRUD, но тогда о каком PATCH мы можем говорить...

а я имею) Еще раз для смены пароля нужны три поля: старый пароль, новый пароль и емейл. Для смены мейла два поля: пароль и емейл. Как ты отличаешь, что забыли указать новый пароль и кидаешь ошибку от запроса на смену емейла?

$errors = $userValidator->validate($user) методы внутри валидации: 1. if ($newPassword) {checkOldPassword($oldPass), checkEmail()}; 2. if ($newEmail) {checkOldPassword()); Так как ты не передал новый пароль - упадет 1 валидация, и дальше интерпритатор не пойдет.

$errors = $userValidator->validate($user) методы внутри валидации: 1. if ($newPassword) {checkOldPassword($oldPass), checkEmail()}; 2. if ($newEmail) {checkOldPassword()); Так как ты не передал новый пароль - упадет 1 валидация, и дальше интерпритатор не пойдет.

но для смены email-а все ж вполне валидно

И ЧО

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

где твоя атомарность блЕЯТЬ

$errors = $userValidator->validate($user) методы внутри валидации: 1. if ($newPassword) {checkOldPassword($oldPass), checkEmail()}; 2. if ($newEmail) {checkOldPassword()); Так как ты не передал новый пароль - упадет 1 валидация, и дальше интерпритатор не пойдет.

а как мыло сменить о.о

не пиши баги в клиенте

если на клиенте одна форма - заполни ее правильно. Если две, передавай только новый емейл и пароль

если на клиенте одна форма - заполни ее правильно. Если две, передавай только новый емейл и пароль

так у тебя ж первая проверка падать будет постоянно

почему? Новый пароль не передан - нету проверки

почему? Новый пароль не передан - нету проверки

как ты собираешься отличать undefined от непередан?

ебать, а как у тебя в PHP выглядит undefined

никак, подсказка

если ты докалебываешься до псевдокода, то давай поговорим о псевдокоде.

никак, подсказка

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

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

так вот нет, надо ошибку кинуть 400, если запрос некорректный)

Он же корректный, ты только про емейл спрашивал.... бля я устал.

PATCH не должен передавать все поля

короч я понял как ты это видишь

Короче, Да серега, я так делаю, и пока я не разрабатываю фейсбук меня все устраивает (и устраивало). Если у меня будут намеки на пиздец сложные запросы, то я заюзая graphql а там почти тоже самое (CRUD LIKE) (сча опять полетят помидоры :( ) только можно выбирать еще извращеннее, и вот там уже есть роутинг на уровне запросов.

Он же корректный, ты только про емейл спрашивал.... бля я устал.

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