REST vs JSON-RPC? [cerrado]

Estoy tratando de elegir entre REST y JSON-RPC para desarrollar una API para una aplicación web. ¿Cómo se comparan?

Actualización 2015: he encontrado que REST es más fácil de desarrollar y usar para una API que se sirve en Web / HTTP, porque la API puede aprovechar el protocolo HTTP existente y maduro que tanto el cliente como el servidor pueden aprovechar. Por ejemplo, la API puede utilizar códigos de respuesta, encabezados, consultas, cuerpos de publicación, almacenamiento en caché y muchas otras funciones sin ningún esfuerzo o configuración adicional.

El problema fundamental con RPC es el acoplamiento. Los clientes RPC se acoplan estrechamente a la implementación del servicio de varias maneras y se hace muy difícil cambiar la implementación del servicio sin interrumpir a los clientes:

• Los clientes deben conocer los nombres de los procedimientos;
• Parámetros de procedimiento orden, tipos y materias de conteo. No es tan fácil cambiar las firmas de procedimientos (número de argumentos, orden de argumentos, tipos de argumentos, etc.) en el lado del servidor sin interrumpir las implementaciones del cliente;
• El estilo RPC no expone nada más que puntos finales de procedimiento + argumentos de procedimiento. Es imposible que el cliente determine qué se puede hacer a continuación.

Por otro lado, en el estilo REST es muy fácil guiar a los clientes al incluir información de control en las representaciones (encabezados HTTP + representación). Por ejemplo:

• Es posible (y de hecho obligatorio) incrustar enlaces anotados con tipos de relaciones de enlace que transmiten el significado de estos URI;
• Las implementaciones del cliente no necesitan depender de nombres de procedimientos y argumentos particulares. En cambio, los clientes dependen de los formatos de mensaje. Esto crea la posibilidad de usar bibliotecas ya implementadas para formatos de medios particulares (por ejemplo, Atom, HTML, Collection + JSON, HAL, etc.)
• Es posible cambiar fácilmente los URI sin interrumpir a los clientes, siempre que solo dependan de las relaciones de enlace registradas (o específicas del dominio);
• Es posible incrustar estructuras con forma de formulario en representaciones, dando a los clientes la posibilidad de exponer estas descripciones como capacidades de IU si el usuario final es humano;
• El soporte para el almacenamiento en caché es una ventaja adicional;
• Códigos de estado estandarizados;

Hay muchas más diferencias y ventajas en el lado REST.

He explorado el problema con cierto detalle y decidí que REST puro es demasiado limitante, y RPC es lo mejor, aunque la mayoría de mis aplicaciones son CRUD. Si se apega a REST, eventualmente se estará rascando la cabeza preguntándose cómo puede agregar fácilmente otro método necesario a su API para algún propósito especial. En muchos casos, la única forma de hacerlo con REST es crear otro controlador para él, lo que puede complicar indebidamente su programa.

Si opta por RPC, la única diferencia es que está especificando explícitamente el verbo como parte del URI, que es claro, consistente, menos defectuoso y realmente no tiene problemas. Especialmente si creas una aplicación que va mucho más allá del simple CRUD, RPC es el único camino a seguir. Tengo otro problema con los puristas RESTful: HTTP POST, GET, PUT, DELETE tienen significados definidos en HTTP que REST ha subvertido para que signifiquen otras cosas, simplemente porque encajan la mayor parte del tiempo, pero no todo el tiempo.

En programación, hace mucho tiempo descubrí que tratar de usar una cosa para significar dos cosas va a surgir alguna vez y morderte. Me gusta tener la capacidad de usar POST para casi todas las acciones, ya que proporciona la libertad de enviar y recibir datos según lo necesite su método. No puedes meter al mundo entero en CRUD.

Primero, HTTP-REST es una arquitectura de "transferencia de estado representacional". Esto implica muchas cosas interesantes:

• Su API no tendrá estado y, por lo tanto, será mucho más fácil de diseñar (es realmente fácil olvidar una transición en un autómata complejo) e integrarse con partes de software independientes.
• Se le dirigirá a diseñar métodos de lectura como seguros , que serán fáciles de almacenar en caché e integrar.
• Se le dirigirá a diseñar métodos de escritura como idempotentes , que tratarán mucho mejor con los tiempos de espera.

En segundo lugar, HTTP-REST es totalmente compatible con HTTP (consulte "seguro" e "idempotente" en la parte anterior), por lo tanto, podrá reutilizar las bibliotecas HTTP (existentes para cada idioma existente) y los proxy inversos HTTP, que le proporcionarán la capacidad de implementar funciones avanzadas (caché, autenticación, compresión, redirección, reescritura, registro, etc.) con una línea de código cero.

Por último, pero no menos importante, usar HTTP como protocolo RPC es un gran error según el diseñador de HTTP 1.1 (e inventor de REST): http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2

Grandes respuestas: solo quería aclarar algunos de los comentarios. JSON-RPC es rápido y fácil de consumir, pero como se mencionó, los recursos y parámetros están estrechamente acoplados y tiende a depender de los verbos (api / deleteUser, api / addUser) que usan GET / POST donde-como REST proporciona recursos poco acoplados (api / usuarios) que en una API REST HTTP se basa en varios métodos HTTP (GET, POST, PUT, PATCH, DELETE). REST es un poco más difícil de implementar para desarrolladores inexpertos, pero el estilo se ha convertido en un lugar bastante común ahora y proporciona mucha más flexibilidad a largo plazo (lo que le da a su API una vida más larga).

Además de no tener recursos estrechamente acoplados, REST también le permite evitar comprometerse con un solo tipo de contenido, esto significa que si su cliente necesita recibir los datos en XML, JSON o incluso YAML, si está integrado en su sistema, podría devolver cualquiera de los que usan los encabezados tipo-contenido / aceptar.

Esto le permite mantener su API lo suficientemente flexible como para admitir nuevos tipos de contenido O requisitos del cliente.

Pero lo que realmente separa a REST de JSON-RPC es que sigue una serie de restricciones cuidadosamente pensadas, lo que garantiza la flexibilidad arquitectónica. Estas restricciones incluyen asegurar que el cliente y el servidor puedan evolucionar independientemente uno del otro (puede hacer cambios sin desordenar la aplicación de su cliente), las llamadas no tienen estado (el estado se representa a través de hipermedia), se proporciona una interfaz uniforme para las interacciones, la API se desarrolla en un sistema en capas y el cliente puede almacenar en caché la respuesta. También hay una restricción opcional para proporcionar código a pedido.

Sin embargo, con todo esto dicho: la mayoría de las API no son RESTful (de acuerdo con Fielding) ya que no incorporan hipermedia (enlaces de hipertexto incrustados en la respuesta que ayudan a navegar por la API). La mayoría de las API que encontrará son REST, ya que siguen la mayoría de los conceptos de REST, pero ignoran esta restricción. Sin embargo, cada vez más API están implementando esto y se está convirtiendo en una práctica habitual.

Esto también le brinda cierta flexibilidad, ya que las API dirigidas por hipermedia (como Stormpath) dirigen al cliente a los URI (es decir, si algo cambia, en ciertos casos puede modificar el URI sin un impacto negativo), donde-como con los RPC URI se requiere estático. Con RPC, también necesitará documentar ampliamente estos diferentes URI y explicar cómo funcionan en relación entre sí.

En general, diría que REST es el camino a seguir si desea crear una API flexible y extensible que sea de larga duración. Por esa razón, diría que es el camino a seguir el 99% del tiempo.

Buena suerte Mike

OMI, el punto clave es la acción frente a la orientación de los recursos. REST está orientado a los recursos y se adapta bien a las operaciones CRUD y, dada su semántica conocida, proporciona cierta previsibilidad a un primer usuario, pero cuando se implementa a partir de métodos o procedimientos, lo obliga a proporcionar una traducción artificial al mundo centrado en los recursos. Por otro lado, RPC se adapta perfectamente a las API orientadas a la acción, donde expone servicios, no conjuntos de recursos compatibles con CRUD.

Sin duda, REST es más popular, esto definitivamente agrega algunos puntos si desea exponer la API a un tercero.

Si no (por ejemplo, en caso de crear un front-end AJAX en un SPA), mi elección es RPC. En particular, JSON-RPC, combinado con JSON Schema como lenguaje de descripción, y transportado a través de HTTP o Websockets según el caso de uso.

JSON-RPC es una especificación simple y elegante que define las cargas útiles JSON de solicitud y respuesta que se utilizarán en RPC síncrono o asíncrono.

El esquema JSON es un borrador de especificación que define un formato basado en JSON destinado a describir datos JSON. Al describir los mensajes de entrada y salida de su servicio utilizando el esquema JSON, puede tener una complejidad arbitraria en la estructura del mensaje sin comprometer la usabilidad, y la integración del servicio puede automatizarse.

La elección del protocolo de transporte (HTTP vs websockets) depende de diferentes factores, siendo el más importante si necesita características HTTP (almacenamiento en caché, revalidación, seguridad, idempotencia, tipo de contenido, multiparte, ...) o si su aplicación necesita intercambiarse mensajes a altas frecuencias.

Hasta ahora es mi opinión personal sobre el tema, pero ahora algo que puede ser realmente útil para aquellos desarrolladores de Java que leen estas líneas, el marco en el que he estado trabajando durante el año pasado, surgió de la misma pregunta que se están preguntando ahora. :

http://rpc.brutusin.org

Puede ver una demostración en vivo aquí, que muestra el navegador de repositorio incorporado para pruebas funcionales (gracias al esquema JSON) y una serie de servicios de ejemplo:

http://demo.rpc.brutusin.org

Espero que ayude compañero!

Nacho

Si su servicio funciona bien solo con modelos y el patrón GET / POST / PUT / DELETE, use REST puro.

Estoy de acuerdo en que HTTP está diseñado originalmente para aplicaciones sin estado.

Pero para aplicaciones modernas, más complejas (!) En tiempo real (web) en las que querrá usar Websockets (que a menudo implican estado de estado), ¿por qué no usar ambos? JSON-RPC sobre Websockets es muy ligero, por lo que tiene los siguientes beneficios:

• Actualizaciones instantáneas en cada cliente (defina su propia llamada RPC de servidor a cliente para actualizar los modelos)
• Fácil de agregar complejidad (intente hacer un clon Etherpad con solo REST)
• Si lo hace correctamente (agregue RPC solo como un extra en tiempo real), la mayoría aún se puede usar con REST (excepto si la característica principal es un chat o algo así)

Como solo está diseñando la API del lado del servidor, comience con la definición de modelos REST y luego agregue soporte JSON-RPC según sea necesario, manteniendo el número de llamadas RPC al mínimo.

(y perdón por el uso excesivo de paréntesis)

He sido un gran fanático de REST en el pasado y tiene muchas ventajas sobre RPC en papel. Puede presentar al cliente diferentes tipos de contenido, almacenamiento en caché, reutilización de códigos de estado HTTP, puede guiar al cliente a través de la API y puede incrustar documentación en la API si de todos modos no se explica por sí solo.

Pero mi experiencia ha sido que, en la práctica, esto no se sostiene y, en cambio, haces un montón de trabajo innecesario para hacer todo bien. Además, los códigos de estado HTTP a menudo no se asignan exactamente a la lógica de su dominio y usarlos en su contexto a menudo se siente un poco forzado. Pero lo peor de REST en mi opinión es que pasas mucho tiempo para diseñar tus recursos y las interacciones que permiten. Y cada vez que realice algunas adiciones importantes a su API, espera encontrar una buena solución para agregar la nueva funcionalidad y ya no se ha diseñado en una esquina.

Esto a menudo me parece una pérdida de tiempo porque la mayoría de las veces ya tengo una idea perfectamente clara y obvia sobre cómo modelar una API como un conjunto de llamadas a procedimientos remotos. Y si he hecho todo este esfuerzo para modelar mi problema dentro de las restricciones de REST, ¿el siguiente problema es cómo llamarlo desde el cliente? Nuestros programas se basan en procedimientos de llamada, por lo que construir una buena biblioteca de cliente RPC es fácil, construir una buena biblioteca de cliente REST no tanto y, en la mayoría de los casos, simplemente se asignará de nuevo desde su API REST en el servidor a un conjunto de procedimientos en su cliente biblioteca.

Debido a esto, RPC se siente mucho más simple y más natural para mí hoy. Sin embargo, lo que realmente extraño es un marco coherente que hace que sea fácil escribir servicios RPC que sean autodescriptivos e interoperables. Por lo tanto, creé mi propio proyecto para experimentar nuevas formas de hacer que RPC sea más fácil para mí y tal vez alguien más lo encuentre útil también: https://github.com/aheck/reflectrpc

Según el modelo de madurez de Richardson , la pregunta no es REST vs. RPC , sino ¿cuánto REST ?

Desde este punto de vista, el cumplimiento del estándar REST se puede clasificar en 4 niveles.

• Nivel 0: pensar en términos de acciones y parámetros. Como explica el artículo, esto es esencialmente equivalente a JSON-RPC (el artículo lo explica para XML-RPC, pero los mismos argumentos son válidos para ambos).
• Nivel 1: pensar en términos de recursos. Todo lo relevante para un recurso pertenece a la misma URL
• nivel 2: usa verbos HTTP
• nivel 3: HATEOAS

Según el creador del estándar REST, solo los servicios de nivel 3 pueden llamarse RESTful. Sin embargo, esta es una métrica de cumplimiento , no de calidad. Si solo desea llamar a una función remota que realiza un cálculo, probablemente no tenga sentido tener enlaces hipermedia relevantes en la respuesta, ni diferenciación del comportamiento en función del verbo HTTP utilizado. Por lo tanto, una llamada de este tipo tiende a ser más parecida a RPC. Sin embargo, un nivel de cumplimiento más bajo no significa necesariamente una condición de estado o un acoplamiento más alto. Probablemente, en lugar de pensar REST vs. RPC , deberías usar tanto REST como sea posible, pero no más. No tuerza su aplicación solo para ajustarse a los estándares de cumplimiento RESTful.

Por qué JSON RPC:

En el caso de las API REST, tenemos que definir un controlador para cada funcionalidad / método que podamos necesitar. Como resultado, si tenemos 10 métodos a los que queremos que un cliente pueda acceder, tenemos que escribir 10 controladores para interconectar la solicitud del cliente con un método en particular.

Otro factor es que, aunque tenemos diferentes controladores para cada método / funcionalidad, el cliente debe recordar si usar POST o GET. Esto complica las cosas aún más. Además de eso para enviar datos, uno tiene que establecer el tipo de contenido de la solicitud si se utiliza POST.

En el caso de JSON RPC, las cosas se simplifican enormemente porque la mayoría de los servidores JSONRPC funcionan con métodos POST HTTP y el tipo de contenido es siempre application / json. Esto elimina la carga de recordar utilizar el método HTTP adecuado y la configuración de contenido en el lado del cliente.

No es necesario crear controladores separados para diferentes métodos / funcionalidades que el servidor quiere exponer a un cliente.

¿Por qué descansar?

Tiene URL separadas para diferentes funciones que el servidor desea exponer al lado del cliente. Como resultado, puede incrustar estas URL.

La mayoría de estos puntos son discutibles y dependen completamente de la necesidad de una persona.

Creo que, como siempre, depende ...

REST tiene la gran ventaja de un amplio apoyo público y esto significa muchas herramientas y libros. Si necesita hacer una API que es utilizada por un gran número de consumidores de diferentes organizaciones, entonces es el camino a seguir por una sola razón: es popular. Como protocolo, por supuesto, es una falla total, ya que hay demasiadas formas completamente diferentes de asignar un comando a una URL / verbo / respuesta.

Por lo tanto, cuando escribe una aplicación web de una sola página que necesita hablar con un servidor, creo que REST es demasiado complejo. En esta situación, no tiene que preocuparse por la compatibilidad a largo plazo, ya que la aplicación y la API pueden evolucionar juntas.

Una vez comencé con REST para una aplicación web de una sola página, pero los comandos detallados entre la aplicación web y el servidor rápidamente me volvieron loco. ¿Debo codificarlo como un parámetro de ruta? ¿En el cuerpo? Un parámetro de consulta? Un encabezado? Después del diseño de URL / Verbo / Respuesta, tuve que codificar este desastre en Javascript, el decodificador en Java y luego llamar al método real. Aunque hay muchas herramientas para ello, es realmente complicado no obtener ninguna semántica HTTP en su código de dominio, lo cual es una práctica muy mala. (Cohesión)

Intente crear un archivo Swagger / OpenAPI para un sitio complejo medio y compárelo con una única interfaz Java que describe los procedimientos remotos en ese archivo. El aumento de la complejidad es asombroso.

Por lo tanto, cambié de REST a JSON-RPC para la aplicación web de una sola página. Desarrollé una pequeña biblioteca que codificaba una interfaz Java en el servidor y la enviaba al navegador. En el navegador, esto creó un proxy para el código de la aplicación que devolvió una promesa para cada función.

Nuevamente, REST tiene su lugar solo porque es famoso y, por lo tanto, está bien respaldado. También es importante reconocer la filosofía subyacente de los recursos sin estado y el modelo jerárquico. Sin embargo, estos principios se pueden usar con la misma facilidad en un modelo RPC. JSON RPC funciona sobre HTTP, por lo que tiene las mismas ventajas de REST en esta área. La diferencia es que cuando inevitablemente te encuentras con estas funciones que no se corresponden bien con estos principios, no estás obligado a hacer mucho trabajo innecesario.

REST está estrechamente relacionado con HTTP, por lo que si solo expone su API a través de HTTP, REST es más apropiado para la mayoría de las situaciones (pero no para todas). Sin embargo, si necesita exponer su API sobre otros transportes como mensajería o sockets web, REST simplemente no es aplicable.

Sería mejor elegir JSON-RPC entre REST y JSON-RPC para desarrollar una API para una aplicación web que sea más fácil de entender. Se prefiere JSON-RPC porque su mapeo a llamadas de método y comunicaciones se puede entender fácilmente.

Elegir el enfoque más adecuado depende de las limitaciones o del objetivo principal. Por ejemplo, en la medida en que el rendimiento es un rasgo importante, es recomendable optar por JSON-RPC (por ejemplo, computación de alto rendimiento). Sin embargo, si el objetivo principal es ser agnóstico para ofrecer una interfaz genérica para ser inferida por otros, es recomendable optar por REST. Si necesita alcanzar ambos objetivos, es recomendable incluir ambos protocolos.

El hecho que realmente divide REST de JSON-RPC es que rastrea una serie de restricciones cuidadosamente pensadas, lo que confirma la flexibilidad arquitectónica. Las restricciones implican garantizar que el cliente y el servidor puedan crecer independientemente uno del otro (los cambios se pueden hacer sin alterar la aplicación del cliente), las llamadas no tienen estado (el estado se considera hipermedia), un uniforme se ofrece una interfaz para interacciones, la API se avanza en un sistema en capas (Hall, 2010). JSON-RPC es rápido y fácil de consumir, sin embargo, como los recursos mencionados y los parámetros están estrechamente acoplados, es probable que dependa de los verbos (api / addUser, api / deleteUser) que usan GET / POST, mientras que REST ofrece recursos poco acoplados (api / usuarios) en un HTTP. REST API depende de varios métodos HTTP como GET, PUT, POST, DELETE, PATCH.

JSON (denotado como JavaScript Object Notation), que es un formato ligero de intercambio de datos, es fácil de leer y escribir para los humanos. Es fácil para las máquinas analizar y generar. JSON es un formato de texto que es completamente independiente del lenguaje, pero practica convenciones que son conocidas por los programadores de la familia de lenguajes, que consisten en C #, C, C ++, Java, Perl, JavaScript, Python y muchos otros. Tales propiedades hacen que JSON sea un lenguaje perfecto para el intercambio de datos y una mejor opción para elegir.

Pregunta equivocada: ¡impone un maniqueo que no existe!

Puede usar JSON-RPC con "menos verbo" (sin método ) y preservar la estandarización mínima necesaria para la identificación de envío, parámetros, códigos de error y mensajes de advertencia . El estándar JSON-RPC no dice "no puede estar REST", solo dice cómo empacar información básica.

¡"REST JSON-RPC" existe ! es REST con "mejores prácticas", para un embalaje mínimo de información, con contratos simples y sólidos.

Ejemplo

(de esta respuesta y contexto didáctico)

Cuando se trata de REST, generalmente ayuda comenzar por pensar en términos de recursos. En este caso, el recurso no es solo "cuenta bancaria" sino que es una transacción de esa cuenta bancaria ... Pero JSON-RPC no obliga al parámetro "método", todos están codificados por "ruta" del punto final.

• Depósito REST con POST /Bank/Account/John/Transactionsolicitud JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  La respuesta JSON puede ser algo así como{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• RESTO Retirar con POST /Bank/Account/John/Transaction... similar.

• ... GET /Bank/Account/John/Transaction/12345@13... Esto podría devolver un registro JSON de esa transacción exacta (por ejemplo, sus usuarios generalmente desean un registro de débitos y créditos en su cuenta). Algo como {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. La convención sobre la solicitud GET (REST) ​​puede incluir la codificación de la identificación por "@id", por lo que no es necesario enviar ningún JSON, pero sigue utilizando JSON-RPC en el paquete de respuesta.

Si solicita recursos, entonces RESTful API es mejor por diseño. Si solicita algunos datos complicados con muchos parámetros y métodos complicados que no sean CRUD simple, entonces RPC es el camino correcto.

Yo uso vdata para el protocolo RPC: http://vdata.dekuan.org/

1, PHP y JavaScript están bien. 2, la llamada de intercambio de recursos de origen cruzado (CORS) todavía está bien.