Действительно ли API-интерфейс Twitter * RESTful?

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

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

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

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

Надеюсь, это даст достаточный контекст для моего вопроса - может ли это называться "REST"? У меня создается впечатление, что 90% так называемых RESTful реализаций между веб-браузерами и серверами приложений демонстрируют ту же несогласованность, когда ограничения на состояние клиента, хранящиеся на сервере, игнорируются.

Ответ 1

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

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

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

Обновление После ознакомления с авикаторами Twitter немного больше, на самом деле есть альтернативный формат URI, который правильно идентифицирует ресурс избранных. Здесь они показывают, как создать URL-адрес, например:

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

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

Ответ 2

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

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

Из Википедии:

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

Также из Википедии:

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

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

См. также:

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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