даже один метод из lodash дает на выходе бандл размером в полмегабайта

Забандленный lodash+axios и пропущенный через UglifyJsPlugin у меня занимает 93.2KB

Это вы основательно подошли) На айпаде не могу найти вашу игру. Вы ее опубликовали только для телефонов?

Сколько времени потратили на разработку и если не секрет средств?

и это неверный ответ в рамках REST.
потому как current-page роде как иеднтификатор ресурса, но он зависит от предыдущих запросов. и может каждый раз указывать на другой ресурс

Я пожалуй соглашусь, что:

GET current-page
Session: vasya

все-таки не REST (как и с куками), но не потому что:

он зависит от предыдущих запросов. и может каждый раз указывать на другой ресурс

Этот момент уже обсуждался выше.

А потому что неуверен, что так будет правильно:

PUT current-page
Session: vasya

PUT current-page
Session:petya

Также нарушено HATEOAS.

То есть наличие session-id в URL только REST-ful.

Что делать, если установка current-page не была произведена?

404

Об этом и речь.

Это не определение сессионного состояния, это определение того, что должен содержать клиентский запрос.

Это единственное ограничение, указанное Филдингом. Значит, все остальное — позволяется.

И оно нестрогое, потому что формально любой запрос с куками ему соответствует.

Соответствует. Проблема кук не в state.

Из какого пункта описания REST architectural style это следует?

Ни из какого. REST тут не нарушается. Мой fail.

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

Там явно сказано, что имеется ввиду: Each request from client to server must contain all of the information necessary to understand the request..

Что непонятного в запросе?

Все понятно. И это будет REST-ful, если только session header не будет цепляться к каждому запросу без необходимости, как это делают куки, и добавить Vary:Session. Филдинг описывает проблему с куками ни как-то, что они связаны с user-сессией, а именно: The problem is that a cookie is defined as being attached to any future requests for a given set of resource identifiers, usually encompassing an entire site, rather than being associated with the particular application state (the set of currently rendered representations) on the browser.

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

Чем состояние сессии отличается от любого другого состояния, хранящегося на сервере? Состояние сессии может трактоваться так же как и любой другой ресурс? Как насчет этого:

PUT /session/Vasya
< 201 CREATED

GET /session/Vasya
< 200 OK
< {
< «current-page»: "/session/Vasya/current-page"
< }

POST /session/Vasya/current-page
+1
<200 OK

Не, разницы нет никакой — это то же самое сессионное состояние, о котором пишет Филдинг.

После The client-stateless-server style derives from client-server with the additional constraint that no session state is allowed on the server component. он пишет уточнение Each request from client to server must contain all of the information necessary to understand the request. Тут под session state имеется ввиду, некое неявное из запроса состояние, которое образуется на сервере в результате серии запросов от одного и тоже клиента. В результате чего отдельно взятый запрос из этой серии будет непонятен серверу. Но что непонятного для сервера в запросе session/vasya/current-page или pages/current?sessionId=Vasya?

А текущая как определяется?

По sessionID

Vary: Cookie, да.

Спасибо про vary header. Да, с этим хедером запросы будут нормально кешироваться. Значит, проблемы с куками не в кешировании и масштабировании, как я предполагал. Филдинг указывает на другие проблемы с куками, связанные с mis-communication между сервером и клиентом и нарушением приватности из-за того, что они аттачатся к любому запросу (6.3.4.2 Cookies). Решением предлагает использовании context-setting URI. То есть pages/current?sessionId=Vasya будет все-таки REST-ful.

Следующую относительно чего?

Относительно текущей.

Хм, точно ли?

(скажем, ARR по кукам как раз делает sticky session)

В данной нам реализации web ресурс идентифицируется по URL, а не по кукам и URL. Поэтому запрос не кешируется правильно.

ARR? IIS Application Request Routing? Так это приблуда IIS, какое отношение оно имеет к инфраструктуре web?

… но он-то подразумевает, это nextPage.

Зависит от реализации. Это просто может быть указатель на следующую страницу без изменения состояния текущей. Или по-другому — next page может быть точкой отсчета, а current = next-1.

… и чем это отличается от куки, на которых те же сессии делаются обычно?

Тем, что запросы с куками не кешируется и не масштабируется инфраструктурой web, теми же прокси-кэш серверами, например.

Это не самый лучший пример того, чтобы делать так. Скорей как не делать. Но в зависимости от реализации — можно, если переход по такому URL не подразумевает изменения текущей страницы для пользователя. Понятней был бы пример с current page: pages/current?sessionId=Vasya. Тогда на переход на next page сервер бы менял last modified date для current, а пока next page не вызван, current-ответ может быть возвращен из кеша. Ну а масшабируется, потому что ?sessionId=Vasya и ?sessionId=Petya могут быть перенаправлены на обработку разными серверами или закешированы разными прокси.

Например, pages/nextPage не REST, потому что такой запрос нельзя закешировать. А page/nextPage?sessionId=Vasya вполне себе REST.

Добавлю еще, что нужно понимать зачем наложено stateless ограничение на коммуникацию, чтоб потом не возникало непоняток, можно ли и где хранить состояние. А наложено оно в целях реализации масшатибруемости и кеширования. Если ваши запросы будут удовлетворять возможности масштабируемости и кещирования, то можно хранить состояние, хоть на сервере хоть на клиенте.