Является ли Twitter API * действительно * успокаивающим? [закрытый]
Вместе с половиной сообщества веб-разработчиков я изо всех сил старался по-настоящему и по-настоящему грокнуть остальной стиль. Более конкретно, я пытался сформировать некоторые мнения о том, насколько практична чистая архитектура RESTful между веб-браузером и сервером приложений.
В рамках моей учебной работы я рассматривал некоторые онлайн-примеры отдыха, в частности Twitter в этом случае. В своей документации по API они обсуждают различные " REST API Методы".
Я борюсь с рационализацией того, как именно большинство из них на самом деле являются спокойными, помимо наличия спокойной структуры URL. Рассмотрим, например, простой GET-запрос к http://twitter.com/favorites.
В чистой реализации REST я ожидал бы, что идентичные запросы к этому URL, независимо от инициирующего клиента, будут возвращать идентичные ответы. Однако в этом конкретном случае мы, очевидно, увидим разные ответы. в зависимости от наших текущих аутентифицированных пользователей, что подразумевает, что наши запросы подключаются к некоторой форме клиентского состояния на сервере, прежде чем может быть сгенерирован ответ.
Надеюсь, что это дает достаточный контекст для моего вопроса - действительно ли это можно назвать "отдыхом"? У меня складывается впечатление, что 90% так называемых RESTful реализаций между веб-браузерами и серверами приложений демонстрируют ту же самую несогласованность, где ограничения на состояние клиента хранятся на сервер игнорируется.
6 ответов:
Twitter нарушает почти все ограничения на отдых. Ваш пример
На самом деле это вообще не связано с идемпотентностью. Идемпотенция-это способность сделайте один и тот же запрос несколько раз, и он будет иметь тот же эффект. Даже Твиттер отношениях идемпотентности. Если я получаю свои любимые несколько раз, я все равно получаю свои любимые обратно. То, сколько раз я получаю, никак не влияет на результат. Есть много других способов, которыми Twitter нарушает остальные ограничения. Многие из этих вопросов были рассмотрены здесь на SO раньше.http://twitter.com/favorites, возвращающий различные результаты на основе аутентифицированного пользователя, является примером нарушения Twitter ограничения "идентификация ресурсов". Каждый интересный ресурс должен иметь уникальный идентификатор. Мои избранные в Twitter и ваши избранные в Twitter - это два разных ресурса, и поэтому они должны иметь два разных URI.Обновление После изучения документов Twitter api немного больше есть на самом деле альтернативный формат URI, который делает правильно определите ресурс избранное. здесь они показывают, как создать URL-адрес, например:
Это все еще далеко от того, чтобы быть спокойным, но, по крайней мере, это шаг в правильном направлении.http://api.twitter.com/1/favorites/bob.json
В этом контексте идемпотенция-хитрое слово. Даже если вы извлекали отдельный твит, вы получите другой результат, если этот твит был редактируемым и кто-то его редактировал. При получении списка я бы, конечно, ожидал, что твит получит самый последний список.
Возможно, было бы более полезно думать об идемпотенции как о способности делать что-то, не вызывая побочных эффектов. Так что GET в этом смысле идемпотентен, а POST-нет.В информатике термин идемпотент используется для описания методов или вызовы подпрограмм, которые могут быть безопасно звонил несколько раз, как вспомнив процедура однократная или многократная раз имеет тот же результат; т. е. любое количество вызовов метода все переменные имеют то же значение, что и они сделал после первого же звонка. Любой метод или подпрограмма, которая не имеет побочных эффектов также является идемпотентом.
Также из Википедия:
Методы PUT и DELETE определяются для быть идемпотентными, это означает, что несколько идентичные запросы должны иметь тот же эффект, что и от одного запроса.
Напротив, метод POST не является обязательно идемпотентный, так как отправка идентичных запроса POST многократное повторение может еще больше повлиять состояние или вызвать дальнейшие побочные эффекты (например, финансовые операции (например, клиент получает по ошибке плату дважды за один и тот же продукт)).
См. также:
Как я объяснял отдых своей жене
http://tomayko.com/writings/rest-to-my-wife
Глядя на документацию , использование слова "метод", вероятно, является хорошим показателем того, является ли этот API действительно спокойным или нет. Есть несколько ресурсов, которые действительно могут квалифицироваться как таковые, например
friends/<user-id>илиfavourites/<user-id>, но большинство ресурсов на самом деле являются просто процедурами, напримерaccount/update_profile_image.Как я вижу, в REST URI действительно должен просто указать вещь, а не, что вы собираетесь делать с ней. Если есть глагол в URI (например, update), вы, скорее всего, делаете это неправильно.
Как объясняет REST FAQ, термин "REST" используется для охвата широкого спектра вещей, включая приложения с сохранением состояния, которые структурированы в стиле RESTful. Поскольку состояние в основном передается Пользователем в файле cookie, а не хранится на сервере, оно считается спокойным. Рой Филдинг (который изобрел REST) прокомментировал , что до тех пор, пока все состояние передается пользователем, а не Ссылка на состояние на сервере, это RESTful, так как то же самое GET запрос вернет тот же результат. REST API Twitter близок к этому, но не на 100%. Это не совсем оригинальное значение слова "отдых", но интерфейс и общая философия достаточно схожи, чтобы он обычно попадал под один и тот же зонтик.
Технически, нет, это не успокаивает. Это не апатридный (он же идемпотентный, как вы упомянули).