Не зная ничего о вашем приложении, с практической и прагматической точки зрения, переход на REST ничего не даст вам, особенно с учетом потенциальных усилий по разработке.
У вас есть большая клиентская база? У вас много серверов?
Ключевой атрибут (но не единственный и даже не обязательный, но ...) REST - это способ использования HTTP-кэширования.
Вы занимаетесь кэшированием? Это большое дело для вас? Это для больших систем в общедоступном интернете.
Если вы не используете кеширование и не думаете, что это принесет вам большую пользу (т. Е. У вас мало клиентов, ваши серверы не перенасыщены, ваш контент просто не подходит и т. д.), тогда REST, вероятно, даже не стоит использовать, поскольку другие преимущества гораздо менее ощутимы, чем кеширование.
Если вы просто отправляете POX (обычный XML) (или JSON) через HTTP, и это хорошо работает для вас, то я не буду об этом беспокоиться.
Есть и другие преимущества для HTTP, естественно, с его типами мультимедиа, согласованием контента, кэшированием и заголовками местоположения и т. Д. Но, если серьезно, если вы не видите, что многое делает с вашим API, не беспокойтесь.
Если кеширование помогло бы вам, то стоит перейти к более полному охвату протокола и стека HTTP, но для этого нет причин переходить к архитектуре REST. Кэшированный POX через HTTP тоже не REST. Это ... POX через HTTP.
Это все, что SOAP и XML-RPC - это ... POX поверх HTTP, только в SOAP XML есть несколько очень толстых стандартов ...
Если вы - огромная сервисная организация с 10-летним планом, то вы можете подумать о переходе на полноценную REST-архитектуру, поскольку это реальное место в мире - долгосрочные, большие системы.
Но это реальная попытка реинжиниринга пойти по этому пути.
Addenda:
Одной из проблем, которую пытается решить REST, является соединение систем.
Системы RPC, как правило, довольно сильно связаны.
Таким образом, по мере роста систем эта связь становится тормозом эволюции системы.
Рассмотрим две крайности MS Windows и Linux. Microsoft тратит много времени на попытки сделать MS Windows обратно совместимой для работы с устаревшим (и даже с ошибками) программным обеспечением. Это стоит им времени и денег.
Напротив, ядро Linux намного более кавалернее. Когда дело доходит до ядра, они не дают никаких обещаний по поводу обратной совместимости. Linux славится тем, что он ломает драйверы и что не от релиза до релиза. Их главная спасительная милость в том, что они ничего не обещали, поэтому не расстраивайтесь, когда что-то ломается.
Это позволяет людям ядра Linux быть более креативными и двигаться быстрее, потому что они всегда могут подбрасывать и изменять вещи по мере продвижения. Это также позволяет команде быть меньше.
Теперь рассмотрим небольшую систему сервисов RPC. Поскольку они неявно тесно связаны (как это характерно для RPC), при изменении центральной службы это изменение будет распространяться на всех клиентов.
Если таких клиентов немного, и особенно если они находятся под вашим контролем (поскольку вы разрабатываете всю систему, а не компонент), масштаб изменений не обязательно будет болезненным и разрушительным.
Но вы можете видеть, что если у вас были тысячи клиентов и / или клиентов, которых вы не контролируете, внедряя спецификации, внесение изменений в основные службы может иметь серьезные последствия. Черт возьми, я послал людям исходный код, и они все еще не правы.
REST помогает отделить системы, используя стандартные типы мультимедиа (то есть не какой-то XML, который вы бросили на доску за один день), HTTP-протокол (вам не нужен HTTP, чтобы иметь REST-арку, но это в значительной степени дано сегодня), и HATEOS.
HATEOS, примерно, где клиент не делает никаких предположений о том, куда идут дела. Вместо этого клиент анализирует результаты на наличие ссылок на следующие шаги в процессе, который он выполняет.
Классический пример - вы (клиент), делающий покупки Amazon. Все, что вам известно, - это нажать кнопку «Оформить заказ», но вы не знаете, по какому URL перейти. Этот URL может быть зафиксирован в камне, он может меняться каждую секунду, он может даже привести к тому, что вас перенаправит. ВЫ не знаете и не заботитесь. Это прерогатива серверов.
Итак, будучи клиентом, вы знаете, как «щелкнуть извлечение» (т. Е. Перейти по ссылке в самой последней полезной нагрузке с пометкой «оформить заказ»), но вы действительно не знаете намного больше. Примечательно, что у вас нет жестко закодированного http://amazon.com/checkout" в вашем приложении.
Не вдаваясь в подробности того, как использование этих концепций уменьшает связность, на данном этапе просто соглашайтесь с тем, что они делают, и, уменьшая связность, вы, как поставщик услуг, получаете более простой механизм для расширения, добавления и изменения служб, а в качестве службы. Потребитель, вы можете сфокусировать свою систему на тех аспектах услуги, которые вас особенно интересуют, даже если за вашей спиной меняются некоторые детали. Опять же, подумайте, насколько Amazon изменился за эти годы, но, по крайней мере, мы все знаем, где находится кнопка «Оформить заказ».
Но написание подобных сервисов и создание таких клиентов - это совсем немного работы. Некоторые из механизмов «просты», потому что «мы делаем это все время» (например, раздача ответов HTML, кто этого не делает?). Но больший объем работы с типами мультимедиа, облегчение изменений и эволюции, а также обеспечение надежности и дружественности ваших услуг и клиентов к этой среде. Это все требует работы, потому что выгоды не сразу понял.
«Почему мы делаем все это для службы, которая никогда не изменится?»
"Потому что никогда не приходит раньше, чем вы думаете."
Веб-приложения (такие как Amazon) успешно работают RESTy, потому что их клиенты оказываются людьми, которые оказываются (в основном) вполне адаптируемыми. Но если вы когда-либо перемещали кнопку какой-либо основной функции на популярном веб-сайте, ваш почтовый ящик позволяет узнать, насколько реально адаптируются некоторые люди. Делать это на уровне машины еще сложнее.
Имейте в виду, это резко контрастирует с "не создавайте его, если он вам не нужен", "гибким", мы можем просто добавить это позже "мышление.
Вот почему REST лучше подходит для больших систем с долгосрочными перспективами. Это гораздо более стратегический, чем тактический. Это больше, чем просто вставлять биты через сокет, чтобы получить результат.
Надеюсь, это поможет.