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