REST vs JSON-RPC? [cerrado]

251

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.

Ali Shakiba
fuente
29
REST es definitivamente la respuesta popular en este momento. Sin embargo, no estoy convencido de que siempre sea la respuesta correcta. Podría haber una falta de coincidencia de impedancia entre una API REST centrada en los recursos y un dominio problemático que está inherentemente basado en tareas o flujos de trabajo. Si descubre que tiene que hacer diferentes tipos de PARCHES para el mismo recurso o que ciertas tareas no se asignan a un recurso específico, entonces debe comenzar a doblar el paradigma REST. ¿Utiliza acciones / comandos como recursos? ¿Diferencia los tipos de comando en el encabezado Content-Type como parámetros? No estoy seguro de que haya una respuesta única para todos.
Landon Poch
27
JSON-RPC es simple y consistente, un placer de usar.
dnault
1
En agosto de 2015, implementé tanto el cliente como el servidor usando REST, los primeros 2 días aprendí y luego entendí por qué era popular. Fue una verdadera alegría una vez que se creó una pequeña aplicación, el cliente realmente no tiene trabajo para recordar varias rutas de URL, el servidor en node.js y el cliente en JavaScript compartieron la misma estructura (rutas de URL) para comunicarse. ¡Guauu! fue muy rápido, el producto se entregó en solo 15 días, incluso escribiendo desde cero. DESCANSO es el camino a seguir. También tenga en cuenta que Popular Apache CouchDB usa REST, una gran base de datos, también están muy orgullosos de haberlo hecho en REST. En simple, REST es CORRECTO (correcto) con una interfaz limpia.
Manohar Reddy Poreddy
66
Depende de las limitaciones que tenga o de su objetivo principal. Por ejemplo, si el rendimiento es un aspecto importante, su camino a seguir es JSON-RPC (por ejemplo, informática de alto rendimiento). Si su objetivo principal es ser agnóstico para proporcionar una interfaz genérica para que otros la interpreten, su camino a seguir es REST. Si desea ambos objetivos, debe incluir ambos protocolos. Sus necesidades definen la solución.
Stathis Andronikos
@StathisAndronikos Tienes razón, mi objetivo principal era la facilidad de uso y un buen rendimiento para las aplicaciones web (no HPC).
Ali Shakiba

Respuestas:

221

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.

ioseb
fuente
20
¿Qué quiere decir con "es obligatorio incrustar enlaces anotados con tipos de relación de enlace que transmiten significados ..."?
pjz
129129
"Los clientes deben conocer los nombres de los procedimientos"; eso no es argumento porque con REST este nombre está codificado en el URI en lugar de pasarlo como parámetro. De lo contrario, el servidor no sabrá qué método debe realizar.
Centurion
44
"No es tan fácil cambiar las firmas de procedimientos ... en el lado del servidor sin romper las implementaciones del cliente", esto también es discutible. Tanto REST como JSON-RPC no son SOAP y no tienen WSDL que describa los servicios web existentes y sus tipos para que puedan usarse para un cambio dinámico en el lado del cliente. Entonces, de cualquier manera, si cambia el servicio web, debe cambiar el cliente. De lo contrario, debe ir con SOAP.
Centurion
64
He codificado una dosis de aplicaciones y aún no he visto ningún servicio web flexible. Si cambia el backend y los servicios web, el cliente siempre necesita ser refactorizado / actualizado para ajustarse a los nuevos requisitos. Y he mencionado SOAP y porque tiene algo que le da flexibilidad, como WSDL, para que pueda automatizar algo y tener más flexibilidad porque puede obtener información sobre el conjunto de resultados, los tipos de datos y los servicios web disponibles. REST y otros no tienen eso en absoluto. Entonces, ni REST, ni JSON-RPC, ni otro tipo de servicio web le proporcionarán magia que eliminaría la necesidad de una actualización manual del cliente.
Centurion
15
Para mí, mi equipo actual y los equipos anteriores, los servicios web RESTful son para aplicaciones de tipo CRUD. Con respecto a "¿Reescribimos los navegadores cada vez que algo cambia en el servidor?" - no, debido a que los navegadores son solo ejecutores HTTP, no tienen nada que ver con la lógica de negocios, que el programa cliente necesita implementar (mostrar pantallas, realizar cosas relacionadas). Parece que hemos comenzado la guerra de las llamas, pero en general desearía tener otra fuente sólida para los servicios web RESTfull con un flujo de uso práctico, con flexibilidad mágica a la que se refiere. Mientras tanto, muchas declaraciones son demasiado vagas.
Centurión
163

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.

Bruce Patin
fuente
30
Esta respuesta muestra la idea errónea demasiado habitual de lo que realmente es REST. REST definitivamente no es solo un mapeo de CRUD a métodos HTTP. La idea de que es un problema "agregar otro método" indica claramente que REST se entiende mal como RPC sobre HTTP, lo cual no es en absoluto. Intente leer el blog de Roy Fieldings o su disertación, Google lo ayudará a encontrarlo, no está describiendo REST en absoluto en su respuesta.
nepdev
68
Soy una persona muy practica. Todas las descripciones de REST que he leído claramente comienzan con un mapeo de CRUD a métodos HTTP. Se permite agregar más teóricamente, pero en la práctica, no. Como ejemplo, recientemente quería implementar PATCH para dispositivos Android, pero descubrí que Android no permite PATCH, por lo que utilicé POST con una acción definida explícitamente para ese efecto en el URI. Básicamente, REST puro no hará los trabajos que requiero, así que uso lo que funciona.
Bruce Patin
44
Entonces, @BrucePatin, en su versión "REST", ¿tiene un controlador con cuatro métodos públicos que asignan 1 a 1 con GET | PUT | POST | DELETE? Algunos marcos hacen eso, pero eso no es REST. Los verbos HTTP hacen vagas afirmaciones abstractas sobre la semántica de una solicitud dada. Tienes que mapear tus puntos finales en esas clases adecuadamente. GET podría mapearse a muchos puntos finales diferentes, al igual que los demás. De hecho, no hay ninguna razón por la que no pueda implementar REST-ful JSON-RPC sobre HTTP.
spinkus
55
Hay una muy buena razón. Es posible que desee varias docenas de acciones, y ya me he encontrado con un uso común (Android) que ni siquiera admite PATCH. Eso lo mata de frío. Prefiero ser coherente que tener que lidiar con varias excepciones a la regla. En general, ahora solo usaré GET, POST y DELETE. PUT no permite la retroalimentación que quisiera en una operación de actualización. Estoy usando POST para casi todo. Con respecto al almacenamiento en caché, ha causado muchos problemas al devolver datos antiguos. Con respecto a la colocación de parámetros en POST, ASP.NET ya lo maneja automáticamente desde objetos JSON automáticos.
Bruce Patin
22
Creo que las disputas sobre lo que REST realmente es solo subraya sus comentarios y destaca una gran deficiencia de REST. Conceptualmente es difícil encontrar dos personas que estén completamente de acuerdo en lo que es RESTful. De todos modos, no importa porque ningún servicio debe ir RPC o REST indocumentado. Si está documentado, el desarrollador que lo usa no debería tener problemas.
Agile Jedi
29

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

Aurélien
fuente
1
+1 para la referencia autorizada, tipo que debería saber ... Es difícil argumentar a favor de RPC sobre HTTP después de eso, sin reconocerlo como un truco / solución alternativa ...
RJB
99
Acabas de hacer referencia a algo del 2000. Es más un argumento filosófico para REST versus RPC. Semánticamente y aplicando un patrón RPC, puede considerar fácilmente que el URI es el "procedimiento" y que los parámetros codificados son ... bueno ... los parámetros. Cualquiera de los patrones funcionaría bien sobre HTTP. Lo mismo con SOAP, RAILS o cualquier otro número de patrones / protocolos que se han superpuesto en HTTP. No importa siempre que ofrezca una API consistente que no rompa su contrato.
Agile Jedi
Aurélien, ¿podría justificar por qué REST es más fácil de integrar con partes de software independientes? Para mí, independientemente de si usa RESTful API o RPC, el software del cliente necesita saber el formato de su API.
Alexey
1
@Alexey Este argumento era relativo a la apatridia. Es más fácil de integrar una máquina de café cuya API es CREATE CUP, que otro que contendría INSERT COIN, SELECT COFFEE, SELECT SUGAR, y START. En la segunda API, debido a que depende del estado de la máquina, debe tener mucho cuidado con la secuencia de llamadas a procedimientos.
Aurélien
1
HTTP como protocolo RPC es REST. Entonces su interpretación incorrecta es sorprendentemente al revés.
Tiberiu-Ionuț Stan
24

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

Mike Stowe
fuente
3
no es LIGERAMENTE más difícil, sino que es extremadamente más difícil. He estado tratando de entenderlo durante 4 meses más o menos, y todavía no tengo un buen manejo de cómo escribir un servicio que no se convierta en un RPC sin estado a través de http usando json, y todavía no estoy convencido hay una diferencia real entre "REST" y lo que acabo de decir
Austin_Anderson
19

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

idelvall
fuente
¡Es genial encontrar un espíritu afín! Estoy trabajando en algo similar aquí: github.com/dnault/therapi-json-rpc
dnault
:) Lo investigaré
idelvall
1
De acuerdo con esto REST funciona bien para las API CRUD ya que tiene la POST / GET / PUT / DELETE obvia [PoGPuD? ;)] mapeo. Sin embargo, si su API no se ajusta cómodamente a esos verbos, JSON-RPC puede ser una buena opción, ya que los verbos solo confundirán las cosas. Entonces, sí, quién lo está usando y por qué es un factor importante.
Algy Taylor
1
Exactamente: REST es el reino de los sustantivos, JSON-RPC son verbos.
Rob Grant
16

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)

cbix
fuente
15

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

ahe
fuente
Echa un vistazo a OpenRPC, debería resolver tu necesidad de "servicios RPC fáciles de escribir que sean autodescriptivos e interoperables"
Belfordz
11

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.

nota azul
fuente
1
+1 para los niveles 0, 1 y 2. Sin embargo, nunca he visto una implementación exitosa de HATEOS, pero he visto dos intentos fallidos miserablemente.
mjhm
8

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.

Umer Farooq
fuente
3

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.

Peter Kriens
fuente
1
Esta respuesta me hizo darme cuenta de las similitudes entre GraphQL y JSON-RPC y por qué GraphQL se está convirtiendo en una opción popular para los SPA.
Dennis
OpenRPC es el equivalente a OpenAPI / Swagger, pero para JSON-RPC
Belfordz
1

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.

dtoux
fuente
2
REST es un estilo arquitectónico y no depende del protocolo.
Mark Cidade
44
Tienes razón, REST es un principio arquitectónico. Sin embargo, su base teórica estuvo fuertemente influenciada por el protocolo HTTP y, a pesar de la afirmación de aplicabilidad universal, no encontró ninguna aplicación práctica más allá del dominio web. Por lo tanto, es seguro decir que cuando alguien menciona REST se refieren a servicios web y no al principio arquitectónico.
dtoux
1

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.

SinghKunal
fuente
"Es fácil analizar las máquinas sin problemas" - He visto muchos JSON rotos (por ejemplo, cotizaciones sin escape en la carga útil)
alancalvitti
1

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.

Peter Krauss
fuente
Ver también stackoverflow.com/a/13952665/287948
Peter Krauss
0

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.

Adrian Liu
fuente
Esta es una gran simplificación excesiva del tema. ¿Por qué, específicamente, es "Mejor por diseño"? JSON-RPC puede ser tan simple o complicado como desee, por lo que el argumento de que es "mejor" para "muchos parámetros y métodos complicados" también es falso. No es mejor ni peor en este asunto.
Belfordz
No importa si el RPC usa JSON o protobuf o XML para serializar los datos. El punto clave es la API como dije. No quiero decir que uno sea mejor que el otro en todos los casos. Pero sí creo que los parámetros y métodos son importantes cuando eliges entre las dos implementaciones. Si son simples, la mayoría de los programadores entienden bien la API RESTful y usted puede construir fácilmente la solicitud http. Si son complicados, RPC es más capaz de expresar tales API, y su IDE y compilador pueden ayudarlo con eso.
Adrian Liu
-1

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.

Liu Qixing
fuente