services api rest xml-rpc

api - services - XML-RPC vs REST



json rpc (2)

Las implementaciones REST vs RPC como XML-RPC son una falsa dicotomía. Puede implementar una interfaz RESTful utilizando XML-RPC (aunque probablemente no quiera). Dicho esto, hay un montón de razones por las que querría exponer los recursos de forma RESTABLECIDA utilizando HTTP vainilla en lugar de utilizar su propia interfaz RPC utilizando una tecnología como XML-RPC:

  1. Las acciones futuras son controladas principalmente por el servidor en lugar de codificadas en el cliente a través de llamadas a procedimientos, simplificando 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 utilizar de forma inmediata.
  3. Es probable que los procedimientos personalizados que usted utiliza con una interfaz RPC tengan un ámbito demasiado estrecho.

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

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

Entonces, ¿puede alguien aquí proporcionar razones prácticas para implementar una API usando REST + JSON en lugar de usar XML-RPC?


  • XML-RPC es una 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 XML-RPC son opacas a la infraestructura de seguridad. Mientras que un firewall con capacidad HTTP podría configurarse para permitir que las llamadas REST lean datos, pero no para actualizarlos o eliminarlos.

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

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

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

    • Las solicitudes REST se benefician de la infraestructura de almacenamiento en caché HTTP, donde todas las llamadas XML-RPC deben ser procesadas por el servidor de destino.
    • REST permite al cliente buscar actualizaciones mediante una solicitud HTTP HEAD simple. Para hacer lo mismo en XML-RPC, necesitarías incluirlo en tu API.
  • El cliente XML-RPC debe cargar la respuesta completa en la memoria para que se pueda presentar como un valor de retorno donde sea sencillo para un cliente REST procesar la secuencia a medida que llega. Esto significa que está muy bien que una llamada REST responda con cualquier número de registros donde una API XML-RPC debería limitar el tamaño de la respuesta.