Solución:
Considere el siguiente ejemplo de API HTTP que modelan los pedidos que se realizan en un restaurante.
- los 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, etc., pero el nombre del verbo es puramente incidental y no tiene ninguna relación con la funcionalidad real, ya que estás llamando a una URL diferente cada vez. Los códigos de devolución están codificados a mano y forman parte del contrato de servicio.
- los API REST, por el contrario, 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 un pedido:
- RPC: http: // MyRestaurant: 8080 / Orders / GetOrder? OrderNumber = asdf (GET)
- DESCANSO: http: // MyRestaurant: 8080 / Orders / Order? OrderNumber = asdf (GET)
Actualización de un pedido:
- RPC: http: // MyRestaurant: 8080 / Orders / UpdateOrder (PUT: {objeto Pineapple Tacos})
- 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
No puede hacer una separación clara entre REST o RPC con solo mirar lo que publicó.
Una limitación de REST es que debe ser apátrida. 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 ?p={JSON} parámetro.
No sé si su servicio es RPC, pero no es RESTful. Puede aprender sobre la diferencia en línea, aquí hay un artículo para comenzar: Desmontando los mitos de RPC y REST. Usted sabe mejor lo que hay dentro de su servicio, así que compare sus funciones con lo que es RPC y saque sus propias conclusiones.
Como han dicho otros, una diferencia clave es que REST está centrado en el sustantivo y RPC está centrado en el verbo. Solo quería incluir esta tabla clara de ejemplos que demuestran que:
---------------------------+-------------------------------------+-------------------------- Operation | RPC (operation) | REST (resource) ---------------------------+-------------------------------------+-------------------------- Signup | POST /signup | POST /persons ---------------------------+-------------------------------------+-------------------------- Resign | POST /resign | DELETE /persons/1234 ---------------------------+-------------------------------------+-------------------------- Read person | GET /readPerson?personid=1234 | GET /persons/1234 ---------------------------+-------------------------------------+-------------------------- Read person's items list | GET /readUsersItemsList?userid=1234 | GET /persons/1234/items ---------------------------+-------------------------------------+-------------------------- Add item to person's list | POST /addItemToUsersItemsList | POST /persons/1234/items ---------------------------+-------------------------------------+-------------------------- Update item | POST /modifyItem | PUT /items/456 ---------------------------+-------------------------------------+-------------------------- Delete item | POST /removeItem?itemId=456 | DELETE /items/456 ---------------------------+-------------------------------------+--------------------------
Notas
- Como muestra la tabla, REST tiende a usar parámetros de ruta de URL para identificar recursos específicos
(p.ejGET /persons/1234), mientras que RPC tiende a utilizar parámetros de consulta para entradas de funciones.
(p.ejGET /readPerson?personid=1234). - En la tabla no se muestra cómo una API REST manejaría el filtrado, que normalmente implicaría parámetros de consulta (p. Ej.
GET /persons?height=tall). - Tampoco se muestra cómo con cualquiera de los sistemas, cuando crea / actualiza operaciones, es probable que se pasen datos adicionales a través del cuerpo del mensaje (por ejemplo, cuando lo hace
POST /signupoPOST /persons, incluye datos que describen a la nueva persona). - Por supuesto, nada de esto está escrito en piedra, pero le da una idea de lo que es probable que encuentre y cómo podría querer organizar su propia API para mantener la coherencia. Para obtener más información sobre el diseño de URL REST, consulte esta pregunta.