мой вполне мог

но тогда как оно работало вчера

-vvv тоже ничего не пишет ?

http://joxi.net/bmoWjE5tx7EL6m

ну вот как то так сейчас

traceroute -T -p 8701

блокирует кто-то соединение. иди не доходит

raceroute to localhost (127.0.0.1), 30 hops max, 60 byte packets 1 localhost (127.0.0.1) 0.046 ms 0.011 ms 0.011 ms

С сервера ?

на локали

Нужно с сервера

traceroute на серваке такой тулзы нет

а я не рут (

Тогда не понятно есть ли коннект с сервера на порт пк.

получается проблема у меня а не на серваке?

Скорее всего

может подскажешь в какую сторону тогда копать

Мне кажется что где-то закрыты порты. файрвол наверное. или конфинг ssh слетел.(но тут мало вероятно) У меня на работе пока пока мы порты не пробросили ничего не работало.

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

ебаный в рот какой то)

оказалось что был открыт тунель, а на той стороне уже прошел обрыв на сколько я понял

и вот пока я его сам не нашел не убил нифига не работало

оо

ага вот такая фигня

в этом случае id (uuid?) должен генериться на клиенте.

не обязательно

немного размывается разница между PUT и POST

PUT - идемпотентный POST - не идемпотентный. И тот и тот может использоваться как для обновления так и для создания ресурсов. Ну то есть разница только в идемпотентности операции.

ну как бы ээ

повторный пост с тем же id должен фейлить тогда

повторный пост с тем же id должен фейлить тогда

у меня другой вопрос, а почему это id надо на клиенте генерить?

ну мол это норм если тебе надо offline суппорт например но какое это имеет отношение к CQRS?

повторный пост с тем же id должен фейлить тогда

ну вот, не идемпотентная операция. PUT бы не зафэйлился а просто заменил ресурс

у тебя был вопрос, как разделить C и Q

PUT - идемпотентный POST - не идемпотентный. А если по простому?

я так понял, что чистая команда это которая ничего не возвращает

чтобы избавиться от необходимости возвращать объекь UserID, надо генерить его на клиенте

PUT - идемпотентный POST - не идемпотентный. А если по простому?

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

каждый пост меняет состояние

у тебя был вопрос, как разделить C и Q

небыло у меня таких вопросов. У меня был вопрос как их связать)

2 поста подряд переведут систему в состояние отличное от состояние после 1 поста

PUT - идемпотентный POST - не идемпотентный. А если по простому?

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

я так понял, что чистая команда это которая ничего не возвращает

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

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

Это я уже загуглил ) Поэтому и спросил по-простому чтобы)

Так это и есть по простому =)

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

нет. результат не главное. смысл в итоговом состоянии системы

нет. результат не главное. смысл в итоговом состоянии системы

эм.... почитайте определение на википедии

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

ну и я вроде о том же. команда не возвращает вообще ничего.

эм.... почитайте определение на википедии

на википедии алгебраическое определение. в контексте http у него немного другой смысл

на википедии алгебраическое определение. в контексте http у него немного другой смысл

тот же

идемпотентность применительно к http/rest обозначает отсутствие сайд эффектов

но если по простому

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

тот же

нет

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

> Идемпоте́нтность — свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при одинарном

где тут различия с http?

то что под "давать тот же результат" сказали "нет сайд эффектов" это просто трактовка. Смысл тот же

прочитвй определение на w3c

я прочитал)

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

пост может давать всегда пустй 200 ОК, но при этом создавать внутри новый объект

пост может давать всегда пустй 200 ОК, но при этом создавать внутри новый объект

ну так он не идемпотентный

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

а результат = состояние системы

эм.... почитайте определение на википедии

вот этот коммент был о чем?

вот этот коммент был о чем?

к тому что нет различий между термином в контексте http и просто определение идемпотентности

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

по хорошему будет потому что помимо статус кода POST должен возвращать URI ресурса, а он уже будет разный

не будет

ERROR: S client not available

потому что состояние изменилось

но 200 ОК возвращать некорректно, тут не спорю

ладно это все мелочи)

а мой вопрос был.... хочу от контроллеров отказаться0

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

мне оч нравится как сделано в GraphQL

там на уровне запроса определяется что возвращать после операции записи

контроллер это у тебя что?

контроллер это у тебя что?

штука которая связывает http запрос и действия

boundary object т..е.

у меня еще на уровне фронт контроллера происходит отвязка от http

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

public function registerUser(RegisterUser $request, RegisterUserHandler $handler, UserProfileView $view) { $user = $handler($request); return $view($user); }

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

ну ээ

а кто отвязывает http от приложения?

кто создает RegisterUser?

и кто потребитель результата $view?

в моем понимании это как раз контроллер и есть

это все один фронт-контроллер делает?

для всех запросов?

а кто отвязывает http от приложения?

мидалваря, фронт контроллер

кто создает RegisterUser?

мидл варя/фронт контроллер

для всех запросов?

да

а не признак ли это зависимости от фреймворка?

я щас читаю/слушаю про EBI, у меня все через эту призму воспринимается

а не признак ли это зависимости от фреймворка?

ну логика то от него не зависит

и от UI

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

и оно мне мешает

ну как запихнул так и будет

хочу ее оттуда вытянуть