¿Cómo puedo crear una calculadora RESTful?

Question

Dado que los servicios web RESTful se basan en la idea sagrada de que "todo se representa como recursos y se puede acceder mediante una dirección (URI)", esto puede tener sentido para las aplicaciones CRUD (todos los ejemplos son sobre listado/creación/actualización/eliminando entidades). Sin embargo, ¿qué hay de otra lógica empresarial como, por ejemplo, crear un servicio RESTful de calculadora simple que no tiene nada que ver con las operaciones CRUD? ¿Qué puede ser un buen diseño para un servicio REST de este tipo?

En segundo lugar, ¿cuál es la ventaja real de usar REST sobre SOAP si la lógica de SOAP ya tiene sentido?

Answer 1

Un servicio de calculadora sería fácil de modelar de forma RESTful. La "R" en "CRUD" significa "leer", y no hay ninguna razón para que "leer" no pueda significar también "calcular". Así que un simple servicio de Reverse Polish calculadora se podía acceder a través de GET:

GET https://calc.com/rpnCalc?3&4&%2B 
7 

El esquema URI anterior simplemente añade tres parámetros a la solicitud GET:

3 
4 
+ (URL-encoded as %2B) 

Esa es una petición idempotente, segura y almacenable en caché. Si se tratara de una consulta matemática increíblemente complicada que tardó varios minutos en computarse, podría enrutar estas consultas a un proxy HTTP listo para usar y usarlo para devolver instantáneamente cualquier valor precalculado si el mismo URI se consultara repetidamente.

Dependiendo del tipo de cálculos que necesite hacer, también podría ENVIAR una consulta muy compleja a un recurso de la Calculadora (pasando la consulta como el cuerpo de la solicitud) y el servidor podría devolver el URI a un recurso "resultado" , que luego puede OBTENER para recuperar los resultados e incluso paginar a través de ellos.

En segundo lugar, ¿cuál es la ventaja real de la utilización de SOAP REST sobre si la lógica de jabón ya tiene mucho sentido?

Puedo acceder al servicio de calculadora anterior utilizando una herramienta de línea de comandos como curl sin construir una pieza compleja de SOAP. Puedo codificar las llamadas en segundos sin tener que usar ninguna biblioteca XML de terceros o kit de herramientas SOAP. Puedo utilizar herramientas básicas como los proxies HTTP para almacenar en caché los resultados y mejorar el rendimiento. No tengo que preocuparme por la interoperabilidad de SOAP ni por la compatibilidad con WS-I. Si utilizo los hipervínculos correctamente, entonces puedo evolucionar y mejorar mi servicio sin afectar a los clientes existentes o hacer que incluso recompilen. No hay WSDL a la versión y ningún contrato frágil que deba mantener durante años. Los clientes ya saben qué hacen GET/PUT/POST/DELETE y no es necesario que redefinan o vuelvan a documentar su semántica. Los clientes API que deciden que prefieren JSON en lugar de XML pueden obtenerlo utilizando la característica de negociación de contenido incorporada de HTTP. Puedo hacer absolutamente cero de estas cosas con SOAP y servicios web.

Oye, si SOAP se adapta a tus necesidades, tienes que hacerlo. El uso de REST ofrece muchos beneficios, pero es posible que no sean apropiados para su situación. Por lo menos, aprenda sobre lo que REST puede brindarle con un libro decente like this one y luego decida qué hacer después de obtener la historia completa.

Answer 2

Este es un buen ejemplo de la tensión entre sustantivos y verbos en REST. La sugerencia de usar "agregar" o "sumador" como recurso es tremendamente ingenua. Implica que cada operación se realice como un GET a un "sumador" o "restador". Por supuesto, uno puede hacer que el recurso sea "calcular" pero luego tenemos que usar un verbo. Podemos cambiarlo a "calculadora" o "respuesta", que son sustantivos pero realmente no hemos hecho nada útil.

Answer 3

Un HTTP POST no necesariamente tiene que crear un recurso persistente. En RFC 2616, section 9.5 encontramos:

La acción realizada por el método POST podría no dar lugar a un recurso que puede ser identificado por un URI. En este caso, 200 (OK) o 204 (Sin contenido) es el estado de respuesta apropiado, dependiendo de si o no, la respuesta incluye una entidad que describe el resultado.

Esto significa que podemos pensar en "crear un cálculo" sin tener que persistir el resultado de ese cálculo en su propia URL. Su API podría tener este aspecto:

Request: 
POST /calculations 
Content-Type: text/plain 

3 + 3/12^(3 * PI) 

Response: 
200 OK 
Content-Type: text/plain 

3.005454 

Esto tiene la ventaja de que no está pasando "contenido" a través de la URL, que se romperá cuando intenta enviar un cálculo de largo a través de un cliente o un proxy con una longitud limitada para URLs También puede hacer que soporte diferentes representaciones para solicitudes y respuestas.

Answer 4

Esta pregunta tiene un par de años. Pero aún parece una pregunta que me confunde a mí y a muchos de mis colegas. No hemos podido llegar a una solución que satisfaga a todos.

Pero para una calculadora simple, creo que la implementación de JAXRS a continuación proporciona una API limpia.

/** 
* This class defines a CalculatorResource. 
*/ 

@Path("v{version}/calculators/{id}") 
@Named 
public class CalculatorResource { 

    private final Long value; 

    public CalculatorResource() { 
     value = 0L; 
    } 

    public CalculatorResource(Long initialValue) { 
     this.value = initialValue; 
    } 

    @GET 
    public Long getValue() { 
     return value; 
    } 

    @Path("+{value}") 
    public CalculatorResource add(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value + value); 
    } 

    @Path("-{value}") 
    public CalculatorResource subtract(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value - value); 
    } 

    @Path("*{value}") 
    public CalculatorResource multiply(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value * value); 
    } 

} 

---

Con una IMPLEMENTACIÓN tal, el URI puede ser un fácil leer fórmula.

Por ejemplo./api/v1/calculators/mycalc/+ 9/-4/* 3/+ 10 devolvería 25.