XML-RPC vs RESTO

Question

Esta es una pregunta más teórica. Estoy por construir un pequeño servidor aquí y quiero crear una API para él. Estoy decidiendo qué es mejor y ya descarté SOAP, ya que esa cosa es un desastre en mi opinión. Me queda REST y XML-RPC. Realmente disfruto XML-RPC, es realmente simple de implementar y es lo suficientemente regular como para que todos los clientes puedan usarlo fácilmente. En estos días, todos los chicos geniales están haciendo cosas RESTful, a veces con una carga JSON o documento XML o incluso HTTP POST VARIABLES. Creo que esos muchachos siempre reinventan la rueda para cada servicio. No veo lo que se podría ganar yendo con REST sobre el uso de XML-RPC.

Entonces, ¿alguien aquí puede proporcionar razones prácticas para implementar una API utilizando REST + JSON sobre simplemente usar XML-RPC?

Answer 1

REST vs implementaciones RPC como XML-RPC es una dicotomía falsa. Puede implementar una interfaz RESTful utilizando XML-RPC (aunque probablemente no le interese). Dicho esto, hay un montón de razones por las que se quiere exponer a los recursos de una manera REST utilizando HTTP de vainilla en vez de rodar su propia interfaz RPC utilizando una tecnología como XML-RPC:

1. Las acciones futuras son controlados principalmente por el servidor en lugar de código fijo en el cliente a través de llamadas a procedimientos, lo que simplifica la implementación y el control de versiones.
2. Las implementaciones existentes para cosas como el almacenamiento en caché, la regulación y el control de versiones se pueden usar de inmediato.
3. Es probable que los procedimientos personalizados que se ejecutan con una interfaz RPC tengan un alcance demasiado restringido.

Ver la publicación del blog this para obtener más información.

Answer 2

• XML-RPC está patente gravada. Es posible que un día le pidan que pague una regalía por su uso. Por lo que puedo decir, REST no lo es.

• Las solicitudes de XML-RPC son opacas para la infraestructura de seguridad. Mientras que un firewall con reconocimiento HTTP podría configurarse para permitir que las llamadas REST lean datos pero no para actualizarlos ni eliminarlos.

Las otras ventajas de REST se aplican más a tratar con grandes conjuntos de datos.

• REST es mucho más ligero en el cable (especialmente cuando se usa JSON en lugar de XML).

• XML-RPC ignora la semántica de HTTP. Todas las llamadas XML-RPC son HTTP POST. Esto tiene una serie de implicaciones. Incluyendo que

  • solicitudes REST se benefician de la infraestructura Cacheing HTTP donde todas las llamadas XML-RPC deben ser procesados ​​por el servidor de destino.
  • REST permite al cliente verificar las actualizaciones utilizando una solicitud HTTP HEAD simple. Para hacer lo mismo en XML-RPC, necesitaría construirlo en su API.

• El cliente XML-RPC debe cargar toda la respuesta en la memoria de manera que se puede presentar como un valor de retorno, donde es fácil para un cliente REST para procesar el flujo que llega. Esto significa que está bastante bien que una llamada REST responda con cualquier cantidad de registros donde una API XML-RPC debería limitar el tamaño de la respuesta.