не "спека по rest" - ее не существует

что ее нет знаю

ок, пойду читать, спс

ну короч, основной посыл - урлы - плевать какие, главное в этом все идемпонетность GET/PUT/DELETE/OPTIONS запросов, а так же отсутствие гарантированной идемпонетнтности у POST

ну то есть /users/{id}/1 вместо /users/me только из-за идемпотентности при разных клиентах. Что бы http кэш фурычил. Но сегодня все класть хотели на http кэш а значит вообще плевать

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

Отдавать JSON поверх HTTP -- это рестфул?

а каким макаром они вобще в одной плоскости?

а каким макаром они вобще в одной плоскости?

ну а что ты рестфулом называешь и читал ли диссертацию Филдинга где он термин REST вводит?

сам диссер только в выкладках

в пересказах и т.д. и т.п.

он же потом и писал ЧТО не называть рестфулом)

https://www.slideshare.net/royfielding/a-little-rest-and-relaxation

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

ну короч, все что тебе надо это RPC over http. не стоит юзать то чего не понимаешь. Всеравно получится RPC)

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Думал затеять срач, а ты взял и все испортил ?

пойду матчасть доучивать

всем спасибо

Думал затеять срач, а ты взял и все испортил ?

ну так ты тезисы основные накидывай

i'll be back

Скажите пожалуйста, при работе с ValueObject что принимает VO при изменении

пример

public function change(string $email) : self

или

public function change(UserEmail $email) : self

UserEmail это VO. обычная строка, надо валидировать строку еще. С одной стороны, второй вариант вроде удобнее, однако, мы раскидываем инициализацию new UserEmail по всему проекту

что не оч хорошо.

Скажите пожалуйста, при работе с ValueObject что принимает VO при изменении

vo это объект значение, как ты изменишь цифру 3? тут тоже самое

@oldy777 не совсем понял

@oldy777 не совсем понял

VO это неизменяемый объект.

UserEmail это VO. обычная строка, надо валидировать строку еще. С одной стороны, второй вариант вроде удобнее, однако, мы раскидываем инициализацию new UserEmail по всему проекту

не надо "строку валидировать еще". ты принимаешь обьект UserEmail и 100% уверен что там нормальный email. ибо обьект не создастся если строка будет неправильная

не надо "строку валидировать еще". ты принимаешь обьект UserEmail и 100% уверен что там нормальный email. ибо обьект не создастся если строка будет неправильная

Что-то мне кажется, что ты его не так понял

То есть нчиего страшного что будет где не попадя раскидано ->change(new UserEmail('some@email.com'))

Что-то мне кажется, что ты его не так понял

кстати да :)

или ->compare(new UserEmail('qwe@email.com'))

сейчас уменя вот так ->compare('qwe@qwe.com')

а уже в VO, делаю new self($newEmail)

то есть внутри самого VO в методе, инициализирую, тем самым валидирую новую, входящую строку

а уже в VO, делаю new self($newEmail)

Что-то как-то слишком...

change - это метод VO ?

да

не должно там такого метода быть

ты хрень какую то делаешь :)

не должно там такого метода быть

почему это ?

у меня есть юзер, вызывает родной метод

new VO('mail')->change('mail2') ?

$user->changeEmail('string')

в методе changeEmail

$this->email->change()

в самом VO не надо менять, меняй у юзера

$this->email = VO

$this->email->change()

Красива

@shindakioku ?

$this->email->change()

ужасно :)

@oldy777 а входящие данные какого типа, принимать нвоый VO? Ведь если мы создаем из строки, по идее валидация все-равно будет

$user->changeEmail('new@email.com')

public fucbntion newEmail(string ?? UserEmail $email)

почему это ?

Потому что иммутабельность На кой леший разрешать изменять уже готовый email? Пускай клепает новый объект

@oldy777 а входящие данные какого типа, принимать нвоый VO? Ведь если мы создаем из строки, по идее валидация все-равно будет

просто создаешь новый vo и присваиваешь пользователю

Потому что иммутабельность На кой леший разрешать изменять уже готовый email? Пускай клепает новый объект

я про compare/equals

я про compare/equals

А, тьфу

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

то есть внутри самого VO в методе, инициализирую, тем самым валидирую новую, входящую строку

я про compare/equals

я про change

если надо изменить значение vo, то надо просто создать новый)

я про change

soryan

так, еще раз, compare метод должен принимать параметром UserEmail, VO, а метод changeEmail, принимать обычную строку, да?

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

зачем?

@oldy777 immutable

так, еще раз, compare метод должен принимать параметром UserEmail, VO, а метод changeEmail, принимать обычную строку, да?

почему у тебя changeEmail принимает строку??

новый во и всё

просто представь ради прикола, что email в будущем будет не строка.. а наприме огромное число

@oldy777 immutable

ты понимаешь что ты вместо new VO перекладываешь отвественность за создание на сам VO? Т.е. если VO это цифра три, ты на цифру 3 кладешь отвественность за создание других цифр

и весь код твой придется менять

почему у тебя changeEmail принимает строку??

потому что он у него внутри VO

@Adelf32 ааа, тогда да, проще принимать уже VO

@Adelf32 ааа, тогда да, проще принимать уже VO

Так и нужно ?

всем спасибо)

т.е. вы предлагаете ему new VO('email')->changeEmail(new VO('email2')) ??? ))))

нет)

у во нету методов для смены значения

changeEmail должен быть у юзера ?

а у юзера есть метод для смены во)

а вот у него есть :)

ладно, надеюсь он правильно все понял

да

уберу метод change из VO

и принимать надо уже Vo

вы чувствуете?

чувствуете, что мир стал немного, но лучше?

да)

надо тесты поправить)

уберу метод change из VO

Ты ж сам выше написал про иммутабельность ?

он не менет

там cpoy self

Сильна

был