spring-657483_640

Después de la lectura de este artículo, me he quedado un poco sorprendido por la tesis que él se plantea. Tanto que no he podido evitar reseñarlo en el blog.

Dejando aparte que el autor  dice que las APIs REST le parecen desagradables, lo que es un poco subjetivo, vamos a recapitular por qué dice que esta forma de diseñar APIs es mala:

  1. Hay poco acuerdo en lo que significa REST.
    Mi opinión aquí es que no es así exactamente. Dejando aparte que como todo en esto siempre hay un punto de ambigüedad, creo que hay un consenso bastante generalizado de lo que es REST. Incluso creo que hay unas reglas muy sencillas para hacer un API REST (o al menos bastante REST).
  2. El vocabulario REST no está totalmente soportado.
    Esto puede ser así en los browsers como comenta, pero también podemos tener clientes REST que son aplicaciones, como las apps móviles, en los que se puede usar todo el vocabulario.
    En lo que respecta a usar el truco en los navegadores de mandar el verdadero verbo de HTTP (como DELETE) escondido en otro campo, digamos que no queda muy bonito, pero yo lo he usado y es práctico.
  3. El vocabulario no es lo suficientemente rico para las APIs.
    Está claro que no tiene todo el vocabulario, ni podemos expresar toda la semántica de un caso de negocio con los verbos de HTTP, pero yo diría que se aproxima bastante. En definitiva, creo que lo que perdemos en riqueza de vocabulario lo ganamos en sencillez.
  4. Son muy difíciles de depurar.
    Este punto no lo entiendo la verdad, ¿por qué dice que es difícil depurar? ¿Por que hay que saber la URI, el JSON, el código de retorno para poder invocarlo? no lo veo tan complicado.
  5. Están muy acopladas al HTTP.
    Esto es indiscutible, pero lo que hay que preguntarse es ¿Hay algún problema con esto? Me parece que no. El protocolo HTTP está por todos lados, es bien conocido y muy usado. Precisamente por eso es fiable y robusto.

En lugar de REST… JSON-Pure APIs

¿Y que es lo que propone para sustituir a REST?. Su propuesta es un concepto que denomina JSON-Pure APIs, que entre otras, tiene las siguientes características:

  1. Sólo usa un método de transmisión para mandar un request, normalmente un HTTP POST
  2. Separa completamente el contenido del mecanismo de transmisión
  3. Usa un sólo código de respuesta para confirmar la recepción del mensaje, normalmente HTTP Code 200
  4. Separa completamente la respuesta del mecanismo de transmisión.
  5. Es fácil de depurar porque toda la información está contenida en un mensaje JSON fácil de leer, con un vocabulario específico del dominio de negocio
  6. Puede ser fácilmente adaptado a diferentes canales de transmisión, como HTTP/S, Websockets, XMPP, etc.

Y digo yo, que si a todas estas características que propone para esta forma de diseñar APIs, sustituyes JSON por XML, tendremos a un viejo amigo… el SOAP. Precisamente el SOAP es independiente del protocolo de transmisión, usa sólo 200 o 500 como códigos de retorno, está autocontenido en el mensaje (estilo document), etc. etc. Todo eso está muy bien, pero si quieres todas estas características, ¿porque no usar SOAP y la pila WS-*en lugar de inventarse un nuevo estilo de diseñar las API?s.

Precisamente el éxito de las APIs tipo REST (uno de ellos) viene de su sencillez, su ligereza, su levedad… y de utilizar lo que viene de caja en el HTTP. No hace falta inventarse nada (cuanto más se invente más cuesta transmitirlo al resto del equipo y posibles usuarios del API). Todo ya está predefinido, ya se saben los verbos que hay, incluso los códigos de retorno. ¿Por otra parte, queda hoy en día algo que tenga chip y que no soporte le protocolo HTTP? Yo diría que no.

En definitiva, creo que no utilizaré el JSON-Pure APIs 😉 ¿y tú?

Anuncios