Является ли API Twitter действительно * RESTful?

Question

Наряду с половиной сообщества разработчиков веб-сайтов, я изо всех сил пытался на самом деле по-настоящему испытать стиль REST. В частности, я пытаюсь сформулировать некоторые мнения о том, насколько практична чистая RESTful архитектура между веб-браузером и сервером приложений.

В рамках моей учебной деятельности я изучал некоторые онлайн-примеры REST, особенно Twitter в этом случае. В своем API documentation они обсуждают различные «методы API REST».

Я борюсь с рационализацией, как именно большинство из них на самом деле RESTful, за исключением структуры URL RESTful. Рассмотрим, например, простой запрос GET к http://twitter.com/favorites.

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

Надеюсь, это обеспечит достаточный контекст для моего вопроса, тогда - может ли это действительно называться «ОТДЫХ»? Создается впечатление, что 90% так называемых RESTful реализаций между веб-браузерами и серверами приложений демонстрируют ту же несогласованность, когда ограничения на состояние клиента, хранящиеся на сервере, игнорируются.

Answer 1

Twitter ломает почти все ограничения REST. Ваш пример http://twitter.com/favorites, возвращающий разные результаты на основе аутентифицированного пользователя, является примером того, как Twitter нарушает ограничение «Идентификация ресурсов». Каждый интересный ресурс должен иметь уникальный идентификатор. Мои избранные Twitter и ваши избранные Twitter - это два разных ресурса и поэтому должны иметь два разных URI.

Это фактически не связано с идемпотентностью вообще. Идемпотентность заключается в возможности сделать один и тот же запрос несколько раз, и он имеет тот же эффект. Даже Twitter уважает идемпотентность. Если я получу свои фавориты несколько раз, я все равно получаю свои фавориты. Сколько раз я получаю GET, это не влияет на результат.

Существует множество других способов, которыми Twitter разбивает ограничения REST. Многие из этих вопросов были рассмотрены здесь на SO раньше.

Update Ознакомившись АНИ документы Twitter немного больше есть фактически альтернативный URI формат, который делает правильно определить избранного ресурса. Here они показывают, как создать URL, как:

http://api.twitter.com/1/favorites/bob.json 

Это все еще далеко от того RESTful, но, по крайней мере, это шаг в правильном направлении.

Answer 2

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

Возможно, было бы более полезно думать о идемпотенции как о способности делать что-то, не вызывая побочных эффектов. Таким образом, GET является идемпотентным в этом смысле, но POST - нет.

From Wikipedia:

В информатике термин идемпотентный используются для описания методов или вызовов подпрограмм, которые могут быть безопасно называют несколько раз, так как Призывая процедуру один раз или несколько раз имеют тот же результат; то есть после любое количество вызовов метода все переменные имеют то же значение, что и после первого вызова. Любой метод или подпрограмма, которая не имеет побочных эффектов также является идемпотентной.

Также from Wikipedia:

Методы PUT и DELETE определяются как идемпотентным, а это означает, что множественные идентичные запросы должны иметь же эффект, как один запрос.

В противоположность этому, метод POST не обязательно идемпотентна, так как отправки запроса POST идентичную несколько раз может дополнительно влиять на состояние или вызывать побочные эффекты, дополнительно (такие как финансовые операции [например,клиент дважды ошибочно заряжается за тот же товар]).

Смотрите также:

Как Разъяснения REST моей жене
http://tomayko.com/writings/rest-to-my-wife

Answer 3

Технически, нет, это не RESTful. Это не stateless (a.k.a. idempotent, как вы упомянули), во-первых.

Answer 4

Как поясняет REST FAQ, термин «REST» используется для охвата широкого спектра вещей, в том числе приложений с сохранением состояния, которые структурированы в стиле RESTful. Поскольку состояние в основном передается пользователем в cookie, а не хранится на сервере, оно считается RESTful. Рой Филдинг (который изобрел REST) ​​commented, что пока все состояние передается пользователем, а не ссылка на состояние на сервере, это RESTful, так как тот же запрос GET вернет тот же результат. Twitter REST API близок к этому, но не на 100%. Это не совсем оригинальное значение «REST», но интерфейс и общая философия достаточно похожи, что его обычно тянет под одним и тем же зонтиком.

Answer 5

Глядя на documentation, использование слова «метод», вероятно, является хорошим показателем того, действительно ли API действительно RESTful или нет. Есть несколько ресурсов, которые могут действительно квалифицироваться как таковые, например friends/<user-id> или favourites/<user-id>, но большинство ресурсов - это действительно просто процедуры, например, account/update_profile_image.

Как я вижу это, в REST URI должен действительно только specifiy в вещь и не, что вы собираетесь делать с ним. Если в URI есть глагол (например, update), вы, скорее всего, ошибаетесь.

Answer 6

Чтение API Twitter Я понял, что API RESTful устареет через пару недель. Вместо этого вы должны использовать метод аутентификации OAuth.