web services - services - Diferencias de servicios web entre REST y RPC

web service rest (5)

Tengo un servicio web que acepta parámetros JSON y tengo URL específicas para los métodos, por ejemplo:

http://IP:PORT/API/getAllData?p={JSON}

Esto definitivamente no es REST ya que no es apátrida. Tiene en cuenta las cookies y tiene su propia sesión.

¿Es RPC? ¿Cuál es la diferencia entre RPC y REST?

Considere el siguiente ejemplo de API HTTP que modelan pedidos que se colocan en un restaurante.

La API de RPC piensa en términos de "verbos", exponiendo la funcionalidad del restaurante como llamadas de función que aceptan parámetros, e invoca estas funciones a través del verbo HTTP que parece más apropiado: un ''get'' para una consulta, y así sucesivamente, pero el nombre El verbo es puramente incidental y no tiene relación real con la funcionalidad real, ya que cada vez se llama a una URL diferente . Los códigos de devolución están codificados a mano y forman parte del contrato de servicio.
La API REST , en cambio, modela las diversas entidades dentro del dominio del problema como recursos, y usa verbos HTTP para representar transacciones contra estos recursos: POST para crear, PUT para actualizar y GET para leer. Todos estos verbos, invocados en la misma URL , proporcionan una funcionalidad diferente. Los códigos de retorno HTTP comunes se utilizan para transmitir el estado de las solicitudes.

Ordenando:

RPC: http: // MyRestaurant: 8080 / Orders / PlaceOrder (POST: {Tacos object})
REST: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (POST: {Tacos object})

Recuperando una Orden:

RPC: http: // MyRestaurant: 8080 / Orders / GetOrder? OrderNumber = asdf (GET)
REST: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (GET)

Actualización de una orden:

RPC: http: // MyRestaurant: 8080 / Orders / UpdateOrder (PUT: {Pineapple Tacos object})
DESCANSO: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (PUT: {Pineapple Tacos object})

Ejemplo tomado de sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc

Es RPC utilizando http . Una implementación correcta de REST debe ser diferente de RPC. Tener una lógica para procesar datos, como un método / función, es RPC. getAllData () es un método inteligente. REST no puede tener inteligencia, debe ser datos de volcado que pueden ser consultados por una inteligencia externa .

La mayoría de las implementaciones en estos días son RPC, pero muchos lo llaman erróneamente REST porque ven que no están usando XML / Soap sino que usan HTTP + json. REST con HTTP es el salvador y SOAP con XML el villano. Entonces tu confusión está justificada y tienes razón, no es RESTO.

El protocolo http no hace una implementación de REST. Tanto REST (GET, POST, PUT, PATCH, DELETE) como RPC (GET + POST) se pueden desarrollar a través de HTTP (por ejemplo, a través de un proyecto de API web en visual studio). Una lectura muy interesante sobre esto.

RPC es viejo y todos los alumnos saben qué es RPC y la mayoría de los REST desarrollados terminan siendo RPC (HTTP + Json), de manera comprensible. Pero, ¿qué es REST entonces? El modelo de madurez de Richardson dice esto (resumido)

Nivel 0: Http POST
Nivel 1: cada recurso / entidad tiene un URI (pero aún así es solo POST)
Nivel 2: se pueden usar tanto POST como GET
Nivel 3 (REST): utiliza HATEOAS (hipervínculos) o, en otras palabras, vínculos de exploración automática.

por ejemplo, nivel 3:

El enlace indica que este objeto se puede actualizar de esta manera y se puede agregar de esta manera
El enlace indica que este objeto solo se puede leer y así es como lo hacemos.

Has creado sitios web que pueden ser utilizados por humanos. ¿Pero también puedes construir sitios web que sean utilizables por máquinas? Ahí es donde se encuentra el futuro, y los servicios web RESTful le muestran cómo hacerlo.

Este libro de servicios web RESTful ayuda

No se puede hacer una separación clara entre REST o RPC simplemente mirando lo que se publicó.

Una restricción de REST es que tiene que ser sin estado. Si tiene una sesión, entonces tiene un estado, por lo que no puede llamar a su servicio RESTful.

El hecho de que tenga una acción en su URL (es decir, getAllData ) es una indicación hacia RPC. En REST, intercambias representaciones y la operación que realizas está dictada por los verbos HTTP. Además, en REST, la negociación de contenido no se realiza con un parámetro ?p={JSON} .

No sé si su servicio es RPC, pero no es REST. Puede aprender acerca de la diferencia en línea, aquí hay un artículo para comenzar: Desacreditando los mitos de RPC y REST . Usted sabe mejor lo que está dentro de su servicio, así que compare sus funciones con lo que es RPC y saque sus propias conclusiones.

Yo diría así:

¿Mi entidad posee / posee los datos? Luego, RPC: aquí hay una copia de algunos de mis datos, manipule la copia de datos que le envié y devuélvame una copia de su resultado.

¿La entidad llamada posee / posee los datos? Luego DESCANSE: o bien (1) muéstrame una copia de algunos de tus datos o (2) manipula algunos de tus datos.

En última instancia, se trata de qué "lado" de la acción posee / retiene los datos. Y sí, puede usar el lenguaje REST para hablar con un sistema basado en RPC, pero seguirá haciendo actividad RPC cuando lo haga.

Ejemplo 1: tengo un objeto que se comunica con un almacén de base de datos relacional (o cualquier otro tipo de almacén de datos) a través de un DAO. Tiene sentido utilizar el estilo REST para esa interacción entre mi objeto y el objeto de acceso a datos que puede existir como una API. Mi entidad no posee / retiene los datos, la base de datos relacional (o el almacén de datos no relacionales) sí lo hace.

Ejemplo 2: Necesito hacer muchas matemáticas complejas. No quiero cargar un montón de métodos matemáticos en mi objeto, solo quiero pasar algunos valores a otra cosa que pueda hacer todo tipo de matemáticas y obtener un resultado. Entonces el estilo RPC tiene sentido, porque el objeto / entidad matemática expondrá a mi objeto un montón de operaciones. Tenga en cuenta que todos estos métodos podrían estar expuestos como API individuales y podría llamar a cualquiera de ellos con GET. Incluso puedo afirmar que esto es RESTful porque estoy llamando a través de HTTP GET pero realmente bajo las coberturas está RPC. Mi entidad posee / retiene los datos, la entidad remota solo está realizando manipulaciones en las copias de los datos que le envié.

REST se describe mejor para trabajar con los recursos, donde RPC tiene más información sobre las acciones.

REST significa Representational State Transfer. Es una forma sencilla de organizar las interacciones entre sistemas independientes. Las aplicaciones REST usualmente usan solicitudes HTTP para publicar datos (crear y / o actualizar), leer datos (por ejemplo, hacer consultas) y eliminar datos. Por lo tanto, REST puede usar HTTP para las cuatro operaciones CRUD (Crear / Leer / Actualizar / Eliminar).

RPC se utiliza básicamente para comunicarse a través de los diferentes módulos para atender las solicitudes de los usuarios. Por ejemplo, en OpenStack, como nova, vistazo y neutrón trabajan juntos al arrancar una máquina virtual.