Подтвердить что ты не робот

XML-RPC против REST

Это более теоретический вопрос. Я собираюсь создать небольшой сервер здесь и хочу создать для него API. Я решаю, что лучше и уже исключено SOAP, поскольку эта вещь беспорядок на мой взгляд. Я остаюсь с REST и XML-RPC. Мне очень нравится XML-RPC, его очень просто реализовать, и это достаточно регулярно, что все клиенты могут легко его использовать. В эти дни все классные дети делают вещи RESTful, иногда с полезной нагрузкой JSON или XML-документом или даже HTTP POST VARIABLES. Я думаю, что эти ребята всегда изобретают колесо для каждой службы. Я не вижу, что можно получить, перейдя в REST с использованием XML-RPC.

Итак, может ли кто-то здесь предоставить практические причины для внедрения API с использованием REST + JSON только с использованием XML-RPC?

4b9b3361

Ответ 1

REST и RPC-реализации, такие как XML-RPC, являются ложной дихотомией. Вы можете реализовать интерфейс RESTful с помощью XML-RPC (хотя, вероятно, вам этого не захочется). Тем не менее, существует множество причин, по которым вы хотели бы разоблачить ресурсы RESTful способом, используя ванильный HTTP вместо того, чтобы переводить свой собственный интерфейс RPC с помощью технологии, такой как XML-RPC:

  • Будущие действия в основном контролируются сервером, а не жестко закодированы в клиенте с помощью вызовов процедур, упрощая развертывание и управление версиями.
  • Существующие реализации для таких вещей, как кеширование, дросселирование и управление версиями, могут использоваться из коробки.
  • Пользовательские процедуры, которые вы выполняете с интерфейсом RPC, скорее всего, будут слишком узко охвачены.

Подробнее см. этот в блоге.

Ответ 2

  • XML-RPC обременен патентом. Вы можете обнаружить, что однажды вам попросили заплатить роялти за его использование. Насколько я могу судить, REST не является.

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

Другие преимущества REST больше применимы к работе с большими наборами данных.

  • REST намного легче на проводе (особенно при использовании JSON, а не XML).

  • XML-RPC игнорирует семантику HTTP. Все вызовы XML-RPC являются HTTP-сообщениями POST. Это имеет ряд последствий. В том числе, что

    • Запросы REST выигрывают от инфраструктуры кэширования HTTP, где все вызовы XML-RPC должны обрабатываться целевым сервером.
    • REST позволяет клиенту проверять наличие обновлений с помощью простого запроса HTTP HEAD. Чтобы сделать то же самое в XML-RPC, вам нужно будет встроить его в свой API.
  • Клиент XML-RPC должен загружать весь ответ в память, чтобы его можно было представить как возвращаемое значение, когда клиент REST просто обрабатывает поток по мере его поступления. Это означает, что вполне нормально для вызова REST для ответа на любое количество записей, где API XML-RPC должен ограничивать размер ответа.