Понимание REST: СТАНОВЯТСЯ существенно несовместимыми с каким-либо “количеством представлений” счетчик?

Вы смешиваете здесь пару проблем. Один запрос к интерфейсу REST МОЖЕТ инициировать внутреннюю транзакцию. Однако эта транзакция должна начинаться и заканчиваться в рамках одного запроса.
Чего не следует делать интерфейсу REST, так это иметь несколько независимых запросов, участвующих в одной внутренней транзакции "двухфазной фиксации".

Вторая проблема заключается в том, может ли запрос GET выполнять обновления. Как указывает Ян в своем ответе, GET может иметь побочные эффекты при определенных условиях. Он говорит это намного лучше, чем я мог прочитать его ответ, почему.

ИМО избегает обновления статистики в запросе GET, потому что «кто-то так сказал» является догматическим в отношении ReST. Делайте то, что прагматично. Если это связано с обновлением счетчика при ответе на запрос GET, пусть будет так.

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

РЕДАКТИРОВАТЬ: Чтобы ответить на ваш случай с автоматически увеличивающимся счетчиком, спросите себя, какой контекст вы применяете. Очевидно, что если вы определяете ресурс с именем counterThatIncrementsItselfWhenBeingRead , то он либо:

• Нарушает ReSTfulness, поскольку счетчик с увеличением чтения является внутренним противоречивым ресурсом, если единственное правило состоит в том, что GET никогда не может иметь побочных эффектов , или
• Вполне нормально в другом контексте, где вы, например, принимаете во внимание очень короткий срок службы ресурса и выбираете рассматривать приращение как нечто, что происходит после , когда вы прочитали ресурс (или в более общем плане, на усмотрение владельца ресурса)

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

GET безопасен и идемпотентен только в отношении ресурса, указанного в запросе, - это все, что нужно клиенту и должно заботить его.

Самый простой способ подумать об этом - рассмотреть любой механизм, выполняющий такие подсчеты, как посредник (т. Е. Вы используете многоуровневое ограничение), который отслеживает запросы / ответы и обновляет некоторые другие ресурсы подсчета просмотров, а не сам фактический ресурс.

То, что доступ к странице осуществляется через GET, не означает, что нет способа увеличить счетчик. Например, можно использовать AJAX POST.

Я также думаю, что такого рода "пассивные" транзакции можно смело игнорировать. Есть большая разница между посещением URL и удалением объекта где-то, и посещением URL и увеличением счетчика посещений. Однако мне было бы интересно услышать другие мнения на этот счет.

Edit: Я думаю, что мы с Ховардом С в основном согласны, что GET, запускающий счетчик, может быть технически не-RESTful, но это не то, о чем стоит беспокоиться.

POST предназначен для отправки информации, которую клиент предоставляет серверу. Здесь этого не происходит, поэтому POST не требуется.

Для того, чтобы поддерживать HTTP-взаимодействие без состояния (что, как я считаю, является целью REST), GET не обязательно должны вызывать какие-либо изменения состояния; но требуется, чтобы он не скрывал состояния от клиента; то есть любое состояние с будущими последствиями для HTTP-взаимодействия необходимо будет закодировать в пространство URL-адресов, чтобы клиент мог использовать его для обработки будущих запросов.

Счетчик является частью состояния, если и только если его значение будет влиять на будущие взаимодействия - например, если после каждого миллионного приращения срабатывает подсистема «пожалуйста, закажите автобусный тур, на котором мы попытаемся продать вам недвижимость в Орландо» in. REST в основном говорит, что в таких случаях он должен быть частью пространства URL-адресов, поэтому состояние может поддерживаться явно как часть адресации - например, вы можете сгенерировать GET для URL-адреса, для которого строка? counter = Добавляется $ cnt (где $ cnt - значение счетчика).

Если нет, то это просто часть представления - у клиента нет причин передавать его или любую другую основанную на нем информацию обратно на сервер, поэтому нет необходимости, чтобы он присутствовал в URL-адрес (или где-нибудь еще). Вы показываете и отбрасываете.

Один момент, на который вам следует обратить внимание: GET-запросы могут быть инициированы ботами, например, поисковыми системами. Это исказит вашу статистику, если вы их не учтете.

Еще одна мысль:

Я думаю, что «счетчик чтения» не должен увеличиваться. Подумайте о всевозможных ботах / сканерах / приложениях для кэширования, которые не представляют "чтение". Вместо этого может быть какой-то способ вызвать реальное чтение (клиентом).

/ question / 2363294 -> Get возвращает вопрос, но не увеличивает счетчик / question / 2363294 / readCount -> Get возвращает текущий счетчик чтения / question / 2363294 / readCount -> Post обновляет счетчик чтения

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