#http #rest #get
#http #отдых #получить
Вопрос:
Я бы хотел, чтобы запрос возвращал некоторую «аналитику» как часть запроса: самое главное, я бы хотел, чтобы все запросы GET возвращали количество раз, когда был вызван запрос GET.
Является ли это принципиально несовместимым с концепцией RESTful?
Если это не принципиально несовместимо, как я могу заставить мой RESTful-сервер возвращать другой результат для каждого запроса GET, если, по определению этой проблемы, каждый запрос GET означает, что следующий запрос GET должен возвращать что-то другое?
Если это принципиально невозможно сделать RESTful-способом, должен ли я отказаться от REST или вообще отказаться от GET?
P.S: Это мой первый вопрос по SO, поэтому, по-видимому, я не смогу комментировать, пока не наберу 15 повторений, поэтому было бы неплохо, если бы комментаторы / ответчики могли поддержать меня, чтобы я мог быть частью сообщества SO 🙂
Ответ №1:
Здесь в принципе нет несовместимости с REST. Вы должны учитывать тот эффект, что постоянно меняющийся ресурс не выиграет от кэширования (при условии, что вы не хотите, чтобы количество посещений устаревало). Вы также должны учитывать, что это число постоянно «в конечном итоге согласовано»; то есть оно будет представлять количество для некоторого подмножества запросов, если у вас много запросов, выполняемых параллельно. И вам также следует рассмотреть возможность возврата количества в заголовке «X-Visit-Count» вместо основной полезной нагрузки, чтобы сделать функцию более универсальной и избежать загрязнения любой возвращаемой полезной нагрузки и потенциально обеспечить лучшее кэширование. Но нет ничего «против REST», чтобы ресурс возвращал другое представление каждый раз, когда вы его ПОЛУЧАЕТЕ.
Комментарии:
1. черт, я не понимаю (каламбур ; ) У меня сложилось впечатление, что REST означает, что запросы GET были идемпотентными. Как бы я хотел быть «в конечном итоге последовательным»? Установив время истечения в ответе? Так что я бы получил лучшее из обоих миров: по-прежнему разрешать кэширование и при этом быть в конечном итоге последовательным? Кроме того, я не знаю, насколько «загрязняющим» был бы такой счетчик: большинство веб-сайтов в настоящее время (StackOverflow, Google , FaceBook и, в основном, все форумы) четко отображают, сколько просмотров страниц было. Это стало неотъемлемой частью многих веб-сайтов.
2. Идемпотентность имеет значение только для POV вызывающего абонента. Если сервер что-то меняет, то это ответственность сервера. С точки зрения клиента не должно быть разницы между 1 GET и 1000 GET. Итак, если вызывающий абонент намеревается изменить — используйте POST.
3. @Ян Альгермиссен: это очень интересно… В таком случае, как, скажем, StackOverflow, где GET (я полагаю) может вызвать преобразование «просмотрено 9 раз» в «просмотрено 10 раз» , считаете ли вы, что вызывающий объект намеревался или нет изменить?
4. Вызывающий абонент намерен просмотреть страницу. Если вы разработаете бота для перехода на сайт, чтобы увеличить счетчик, я бы счел это злоупотреблением поведением обнаруженного сервера. Кроме того: сервер может реализовать методы, позволяющие повысить точность подсчета просмотров (например, защитить от подсчета нескольких немедленных просмотров одним и тем же клиентом), не влияя на предполагаемый результат.
5. @Jan Algermissen: Сначала я никогда не говорил о ботах 😉 Тогда я не на 100% согласен с «Вызывающий абонент намерен просмотреть страницу».. Дело в том, что «Вызывающий абонент намеревается просмотреть страницу, и на этой странице отображается счетчик, показывающий, сколько раз страница была просмотрена, и вызывающий абонент ожидает увидеть этот счетчик» : именно так работают SO и большинство форумов: они показывают счетчик, и этот счетчик передает очень полезную информацию. Итак… Намеревается ли вызывающий изменить или нет в таком случае?