REST vs RPC para desarrollo móvil

Como muchos saben, el desarrollo móvil se está disparando en estos días y, creo, afecta lo que codificamos. Para ser específicos, estoy interesado en desarrollar servicios web para una aplicación móvil.

Veo dos arquitecturas posibles: RPC y REST. He desarrollado servicios REST y RPC y lo que he observado es que los servicios RPC son mucho más fáciles de codificar, especialmente en lenguajes como PHP. El problema con esto parece ser la escalabilidad: el lado del servidor puede convertirse fácilmente en un desastre cuando hay muchos procedimientos presentes.

REST, por otro lado, parece estar mucho más estructurado, el lado del servidor se vuelve relativamente fácil de mantener, pero tiene el potencial de dividir los datos en múltiples recursos, lo que es malo para las aplicaciones móviles (por múltiples razones).

Por lo que he experimentado, RPC parece un poco mejor en la mayoría de los casos:

• Tanto el lado del cliente como el del servidor están interesados ​​en minimizar el número de procedimientos disponibles y las llamadas realizadas.
• Seguir las reglas arquitectónicas no contrarresta con optimizaciones de otra manera posible.

Realmente no espero que alguien me explique qué son REST y RPC, la web está llena de eso. Quiero que las personas con experiencia en el desarrollo de aplicaciones móviles expresen sus opiniones sobre el uso de estas dos arquitecturas en el lado del servidor. Las propinas también son bienvenidas (¿a quién no le gustan las propinas, eh?).

Hay poca diferencia, RPC tiende a ser más protocolos binarios que REST, pero ese no tiene que ser el caso. También RPC tiende a implementarse como un único punto de procedimiento por llamada, pero de nuevo eso no tiene que ser así: puede implementar un único procedimiento RPC que tome un verbo de estilo REST como primer argumento. RPC a veces tiene un enfoque semi / con estado, pero de nuevo ese no tiene que ser el caso si pasa una 'cookie' con cada llamada.

Hoy en día todo se reduce al soporte de desarrollo, y hay más API REST para lenguajes basados ​​en la web, por lo que las personas usan REST. Si está tomando una vista del desarrollo más centrada en el usuario, entonces probablemente sea mejor con un mecanismo RPC, aprovechando la flexibilidad para proporcionar un protocolo binario más comprimido, luego impleméntelo como desee: procedimiento único que enruta a una rutina basada en un id o 'verbo' y no tiene estado al pasar un id. Todo esto se puede implementar para que parezca muy REST pero con una sobrecarga significativamente menor.

Existen varios sistemas RPC, pruebe las memorias intermedias de protocolo o el ahorro para su aplicación móvil.

Es posible que desee echar un vistazo a este artículo de Netflix sobre su rediseño de API: http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html

TL; DR:

• REST en general causa API hablador: si una operación necesita manipular múltiples recursos, necesitará múltiples llamadas (es decir, ¡lento!)
• Una API no se asigna bien a diferentes consumidores, por lo que Netflix está transfiriendo parte del código del cliente al servidor: cada consumidor puede proporcionar su propio adaptador / capa de orquestación en el servidor para optimizar el acceso de la API a los diferentes consumidores.

Nota personal:

• No asocie RPC con los antiguos protocolos SOAP / CORBA / RMI hinchados de la empresa. Por ejemplo, JSON-RPC es un protocolo muy simple, elegante y ágil para hacer RPC que definitivamente debes considerar.
• REST es perfecto para las API de CRUD. Sin embargo, si su API está muy orientada a la acción, puede que le resulte incómodo asignar esto a verbos / puntos finales REST.