Не думаю, что вы получите хороший ответ на этот вопрос, отчасти потому, что на самом деле никто не согласен с тем, что такое REST . Страница в Википедии содержит много модных слов и мало объяснений. Страница обсуждения стоит того, чтобы посмотреть, сколько людей с этим не согласны. Однако, насколько я могу судить, REST означает следующее:
Вместо того, чтобы иметь произвольно названные URL-адреса для установщиков и получателей и использовать GET для всех получателей и POST для всех установщиков, мы пытаемся, чтобы URL-адреса идентифицировали ресурсы, а затем использовали HTTP-действия GET, POST, PUT и DELETE чтобы что-то с ними сделать. Так что вместо
GET /get_article?id=1
POST /delete_article id=1
Вы бы сделали
GET /articles/1/
DELETE /articles/1/
А затем POST и PUT соответствуют операциям «создать» и «обновить» (но никто не согласен, в какую сторону).
Я думаю, что аргументы кэширования неверны, потому что строки запроса обычно кэшируются, и, кроме того, вам не нужно их использовать. Например, django делает что-то подобное очень простым, и я бы не сказал, что это REST:
GET /get_article/1/
POST /delete_article/ id=1
Или даже просто включить глагол в URL:
GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/
В этом случае GET означает что-то без побочных эффектов, а POST означает что-то, что изменяет данные на сервере. Я думаю, что это, возможно, немного яснее и проще, тем более, что вы можете избежать всего этого PUT -vs- POST. Кроме того, вы можете добавить больше глаголов, если хотите, чтобы вы не были искусственно связаны с тем, что предлагает HTTP. Например:
POST /hide/article/1/
POST /show/article/1/
(или что-то еще, трудно думать о примерах, пока они не произойдут!)
Итак, в заключение я вижу только два преимущества:
- Ваш веб-API может быть чище и проще для понимания / обнаружения.
- При синхронизации данных с веб-сайтом, вероятно, проще использовать REST, потому что вы можете просто сказать
synchronize("/articles/1/") или что-то еще. Это сильно зависит от вашего кода.
Однако я думаю, что есть несколько довольно больших недостатков:
- Не все действия легко сопоставляются с CRUD (создание, чтение / получение, обновление, удаление). Возможно, вы даже не имеете дело с ресурсами типа объекта.
- Это дополнительные усилия для сомнительных выгод.
- Путаница в отношении того, в какую сторону идут
PUT и POST. На английском языке они означают похожие вещи («Я собираюсь разместить / опубликовать объявление на стене»).
Итак, в заключение я бы сказал: если вы действительно не хотите идти на дополнительные усилия или если ваш сервис действительно хорошо соответствует операциям CRUD, сохраните REST для второй версии вашего API.
Я только что натолкнулся на другую проблему с REST: нелегко сделать более одной вещи в одном запросе или указать, какие части составного объекта вы хотите получить. Это особенно важно на мобильных устройствах, где время прохождения сигнала в оба конца может быть значительным, а соединения ненадежными. Например, предположим, что вы получаете сообщения на временной шкале Facebook. «Чистый» способ REST будет выглядеть примерно так:
GET /timeline_posts // Returns a list of post IDs.
GET /timeline_posts/1/ // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....
Что смешно. API Facebook очень хорош для IMO, поэтому давайте посмотрим, что они делают:
По умолчанию большинство свойств объекта возвращаются при выполнении запроса.
Вы можете выбрать поля (или соединения), которые вы хотите вернуть с помощью
Параметр запроса "fields". Например, этот URL будет возвращать только
имя, имя и фотография Бена:
https://graph.facebook.com/bgolub?fields=id,name,picture
Я понятия не имею, как бы вы сделали что-то подобное с REST, и если бы вы это сделали, все равно будет ли это считаться REST. Я бы, конечно, проигнорировал любого, кто пытается сказать вам, что вы не должны этого делать (особенно если причина в том, что «это не ОТДЫХ»)!