Y>Между запросами эта операция должна храниться на сервере? Едва ли это идеологически верно.

Отчасти верно, так как POST по определению может менять/создавать данные на сервере. Тут более уместен вопрос, сколько времени должен храниться на сервере результат выполнения операции, и соответственно время действия токена — через какое-то время результат операции при тех же аргументах станет уже другим (данные, по которым выполняется запрос поменялись) и токен надо уже делать недействительным.

Y>>Между запросами эта операция должна храниться на сервере? Едва ли это идеологически верно.

A>Отчасти верно, так как POST по определению может менять/создавать данные на сервере. Тут более уместен вопрос, сколько времени должен храниться на сервере результат выполнения операции, и соответственно время действия токена — через какое-то время результат операции при тех же аргументах станет уже другим (данные, по которым выполняется запрос поменялись) и токен надо уже делать недействительным.

Ну ОК, я просто подумал про хранение в сессии, а имеется в виду, что создаётся collection для операций, и сервер её чистит по расписанию.

Здравствуйте, andrey82, Вы писали:

A>Отчасти верно, так как POST по определению может менять/создавать данные на сервере. Тут более уместен вопрос, сколько времени должен храниться на сервере результат выполнения операции, и соответственно время действия токена — через какое-то время результат операции при тех же аргументах станет уже другим (данные, по которым выполняется запрос поменялись) и токен надо уже делать недействительным.
Т.е. появляется куча проблем. Мало того, это делает сервис stateful, т.е. лишняя головная боль для load balancer, вставляя палки в колёса scalability. Увеличивает latency — нужно два запроса вместо одного.
Не понимаю, в чём тогда преимущество такого токена? Зачем отдавать токен, если можно отдать данные сразу?

Можно, конечно, придумать ситуации когда это решение лучше, например, когда результаты большие и нужна возможность докачки при обрыве соединения. Но в большинстве случаев "дай мне профили для этих 500 юзеров" лучше подойдёт POST.

Кстати, если так хочется что-то более менее стандартное, можно посмотреть в сторону batch requests, типа такого: http://www.odata.org/documentation/odata-version-3-0/batch-processing/
Т.е. POST-ится "Content-Type: multipart/mixed" c пачкой GET-ов в "Content-Type: application/http".

Здравствуйте, andrey82, Вы писали:

Y>>Между запросами эта операция должна храниться на сервере? Едва ли это идеологически верно.

A>Отчасти верно, так как POST по определению может менять/создавать данные на сервере. Тут более уместен вопрос, сколько времени должен храниться на сервере результат выполнения операции, и соответственно время действия токена — через какое-то время результат операции при тех же аргументах станет уже другим (данные, по которым выполняется запрос поменялись) и токен надо уже делать недействительным.

Зачем хранить токен операции? Назначить соотв. операции гуид и poll'ить по гуиду.

Здравствуйте, yenik, Вы писали:

P>>По человечески это делается через POST метод %create_operation%, который принимает аргументы операции и возвращает токен. Затем по этому токену можно получить результат. Достоинства: идеологически верно, гарантированно не вызывает проблем с HTTP миддлварью, позволяет безболезненно прикрутить CQRS в реализации.

Y>Между запросами эта операция должна храниться на сервере? Едва ли это идеологически верно.

Необязательно храниться, она может и выполняться. А остановить ее можно либо delete'ом либо put'ом.

Здравствуйте, Sharov, Вы писали:

A>>Отчасти верно, так как POST по определению может менять/создавать данные на сервере. Тут более уместен вопрос, сколько времени должен храниться на сервере результат выполнения операции, и соответственно время действия токена — через какое-то время результат операции при тех же аргументах станет уже другим (данные, по которым выполняется запрос поменялись) и токен надо уже делать недействительным.
S>Зачем хранить токен операции? Назначить соотв. операции гуид и poll'ить по гуиду.
Не понял. Этот гуид и будет играть роль токена. Т.е. на сервере нужно сохранять маппинг между результатом операции и гуидом. Вопрос — как долго хранить этот маппинг.

Y>>Между запросами эта операция должна храниться на сервере? Едва ли это идеологически верно.
S>Необязательно храниться, она может и выполняться. А остановить ее можно либо delete'ом либо put'ом.
А если клиенты не будут всегда (будут не всегда) останавливать? Утечка ресурсов?

Здравствуйте, ·, Вы писали:

·>Зато он говорит, что можно выкинуть 414 uri too long, а значит это может сделать любой промежуточный софт на пути http.

Стандарт рекомендует поддерживать как минимум 8000 октетов в URI, что уже плохо увязывается с понятием "небольшой URL".

Здравствуйте, Artem Korneev, Вы писали:

AK>·>Зато он говорит, что можно выкинуть 414 uri too long, а значит это может сделать любой промежуточный софт на пути http.
AK>Стандарт рекомендует поддерживать как минимум 8000 октетов в URI, что уже плохо увязывается с понятием "небольшой URL".
В общем-то относительно небольшой, те же 500 id-шников может уже и не влезть.

Здравствуйте, ·, Вы писали:

S>>Зачем хранить токен операции? Назначить соотв. операции гуид и poll'ить по гуиду.
·>Не понял. Этот гуид и будет играть роль токена. Т.е. на сервере нужно сохранять маппинг между результатом операции и гуидом. Вопрос — как долго хранить этот маппинг.

Ага, тут теперь я понял.

S>>Необязательно храниться, она может и выполняться. А остановить ее можно либо delete'ом либо put'ом.
·>А если клиенты не будут всегда (будут не всегда) останавливать? Утечка ресурсов?

И? Создание html страницы -- это тоже утечка ресурсов. Любое post -- утечка ресурсов. Не вижу проблемы. Решать должен клиент, токен то имеется.

Здравствуйте, Sharov, Вы писали:

S>>>Необязательно храниться, она может и выполняться. А остановить ее можно либо delete'ом либо put'ом.
S>·>А если клиенты не будут всегда (будут не всегда) останавливать? Утечка ресурсов?
S>И? Создание html страницы -- это тоже утечка ресурсов. Любое post -- утечка ресурсов. Не вижу проблемы.
Почему _любое_ post — утечка ресурсов?

S>Решать должен клиент, токен то имеется.
Клиент может токен потерять или сломать. Или клиент вообще может умереть.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Sharov, Вы писали:

S>>>>Необязательно храниться, она может и выполняться. А остановить ее можно либо delete'ом либо put'ом.
S>>·>А если клиенты не будут всегда (будут не всегда) останавливать? Утечка ресурсов?
S>>И? Создание html страницы -- это тоже утечка ресурсов. Любое post -- утечка ресурсов. Не вижу проблемы.
·>Почему _любое_ post — утечка ресурсов?

Блин, по определению. Реальность такова, что чтобы создать что-то необходимо использовать ресурсы (утечка ресурсов на создание). Если мы конечно же говорим о post как о создании ресурсов, а не о get с телом

S>>Решать должен клиент, токен то имеется.
·>Клиент может токен потерять или сломать. Или клиент вообще может умереть.

И? Таймауту предосмотреть для сессии. Еще чего-нибудь придумать. Не вижу здесь проблемы.

Здравствуйте, Sharov, Вы писали:

S>>>>>Необязательно храниться, она может и выполняться. А остановить ее можно либо delete'ом либо put'ом.
S>>>·>А если клиенты не будут всегда (будут не всегда) останавливать? Утечка ресурсов?
S>>>И? Создание html страницы -- это тоже утечка ресурсов. Любое post -- утечка ресурсов. Не вижу проблемы.
S>·>Почему _любое_ post — утечка ресурсов?
S>Блин, по определению. Реальность такова, что чтобы создать что-то необходимо использовать ресурсы (утечка ресурсов на создание). Если мы конечно же говорим о post как о создании ресурсов, а не о get с телом
Теоретически — созданное не всегда нужно сохранять на сервере. Например, в типичном сценарии POST может создать transaction id, используя UUID_Gen или email confirmation с использованием HMAC.

S>>>Решать должен клиент, токен то имеется.
S>·>Клиент может токен потерять или сломать. Или клиент вообще может умереть.
S>И? Таймауту предосмотреть для сессии. Еще чего-нибудь придумать. Не вижу здесь проблемы.
Ну вот... внезапно сессия появилась. А по идее самый производительный rest — stateless.
Таймауты как-то подбирать надо...

Здравствуйте, ·, Вы писали:

·>Теоретически — созданное не всегда нужно сохранять на сервере. Например, в типичном сценарии POST может создать transaction id, используя UUID_Gen или email confirmation с использованием HMAC.

Ресурсы-то в любом случае затрачиваются. В данном случае проц+ram+сетевуха.

S>>И? Таймауту предосмотреть для сессии. Еще чего-нибудь придумать. Не вижу здесь проблемы.
·>Ну вот... внезапно сессия появилась. А по идее самый производительный rest — stateless.

Таки rest будет stateless вне зависимости от сессии. Каждый последующий вызов никак не связан с предыдущим. Сессия здесь побоку.

·>Таймауты как-то подбирать надо...

И не говорите, злости не хватает. А по утрам вообще просыпаться и вставать надо.

Здравствуйте, Sharov, Вы писали:

S>·>Теоретически — созданное не всегда нужно сохранять на сервере. Например, в типичном сценарии POST может создать transaction id, используя UUID_Gen или email confirmation с использованием HMAC.
S>Ресурсы-то в любом случае затрачиваются. В данном случае проц+ram+сетевуха.
Это "возобновляемые ресурсы". Я об утечках. Если поставить сервак и замуровать, то в случае когда утечек нет, он может работать вечно, пока электричество есть. А если есть утечки, то через какое-то время будет "no space on device" или "out of memory".
Можно конечно эти ресурсы грохать по таймауту (expire), но тогда надо как-то доказать, что ресурсов будет достаточно для данного таймаута. Если таймаут сликшом короткий — клиенты могут не успевать. Если слишком длинный — нужен больший размер хранилища.

S>>>И? Таймауту предосмотреть для сессии. Еще чего-нибудь придумать. Не вижу здесь проблемы.
S>·>Ну вот... внезапно сессия появилась. А по идее самый производительный rest — stateless.
S>Таки rest будет stateless вне зависимости от сессии. Каждый последующий вызов никак не связан с предыдущим. Сессия здесь побоку.
Неверно, он связан токеном — второй вызов можно сделать только после первого и в то же место.
Представь это со стороны load balancer. Первый запрос отправляется узлуА и он создаёт токен, второй запрос отправляется узлуБ, потому что узелА нагружен больше, или вообще сдох. Откуда узелБ возьмёт результат?

S>·>Таймауты как-то подбирать надо...
S>И не говорите, злости не хватает. А по утрам вообще просыпаться и вставать надо.
Это лишняя сложность и нагрузка. Где же KISS?

·>Неверно, он связан токеном — второй вызов можно сделать только после первого и в то же место.
·>Представь это со стороны load balancer. Первый запрос отправляется узлуА и он создаёт токен, второй запрос отправляется узлуБ, потому что узелА нагружен больше, или вообще сдох. Откуда узелБ возьмёт результат?

Из общего хранилища / реплицированной копии хранилища узлаА, какие еще варианты?

Здравствуйте, ·, Вы писали:


S>>Ресурсы-то в любом случае затрачиваются. В данном случае проц+ram+сетевуха.
·>Это "возобновляемые ресурсы". Я об утечках.

Я понял, поэтому и предложил таймауты.

·>Можно конечно эти ресурсы грохать по таймауту (expire), но тогда надо как-то доказать, что ресурсов будет достаточно для данного таймаута. Если таймаут сликшом короткий — клиенты могут не успевать. Если слишком длинный — нужен больший размер хранилища.

Нормальная инженерная проблема, решить чем пожертвовать.



·>Неверно, он связан токеном — второй вызов можно сделать только после первого и в то же место.
·>Представь это со стороны load balancer. Первый запрос отправляется узлуА и он создаёт токен, второй запрос отправляется узлуБ, потому что узелА нагружен больше, или вообще сдох. Откуда узелБ возьмёт результат?

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

Здравствуйте, Sharov, Вы писали:

S>·>Можно конечно эти ресурсы грохать по таймауту (expire), но тогда надо как-то доказать, что ресурсов будет достаточно для данного таймаута. Если таймаут сликшом короткий — клиенты могут не успевать. Если слишком длинный — нужен больший размер хранилища.
S>Нормальная инженерная проблема, решить чем пожертвовать.
Вначале создали проблему двумя запросами, а теперь её героически решаем не жалея жертв...

S>>>Таки rest будет stateless вне зависимости от сессии. Каждый последующий вызов никак не связан с предыдущим. Сессия здесь побоку.
S>·>Неверно, он связан токеном — второй вызов можно сделать только после первого и в то же место.
S>·>Представь это со стороны load balancer. Первый запрос отправляется узлуА и он создаёт токен, второй запрос отправляется узлуБ, потому что узелА нагружен больше, или вообще сдох. Откуда узелБ возьмёт результат?
S>В данном конкретном случае, очевидно, что писать в базу или куда еще, чтобы по токену можно было получить результат.
И где же обещанное "stateless"?

Здравствуйте, ·, Вы писали:

S>>В данном конкретном случае, очевидно, что писать в базу или куда еще, чтобы по токену можно было получить результат.
·>И где же обещанное "stateless"?

По кругу ходим: мы вроде договорились, что из-зи токена у нас не stateless, а "stateless"...

Здравствуйте, Sharov, Вы писали:

S>>>В данном конкретном случае, очевидно, что писать в базу или куда еще, чтобы по токену можно было получить результат.
S>·>И где же обещанное "stateless"?
S>По кругу ходим: мы вроде договорились, что из-зи токена у нас не stateless, а "stateless"...
Ничего не понял. не stateless, а "stateless" что значит?

Здравствуйте, ·, Вы писали:

S>>По кругу ходим: мы вроде договорились, что из-зи токена у нас не stateless, а "st
ateless"...

·>Ничего не понял. не stateless, а "stateless" что значит?

Вводим состояние.