El solo hecho de integrar aplicaciones a través de HTTP no significa que estemos usando servicios RESTful. A falta de estándares bien definidos, suele ocurrir que en los equipos de desarrollo no haya consenso sobre si el API de un servicio es realmente RESTful….

Entre las cuestiones que se planten, suelen aparecer estas: ¿Es estrictamente necesario retornar enlaces a recursos en lugar de codificar los valores en el resultado de una operación?, ¿Hay que usar todos los métodos de HTTP? ¿POST vs PUT para crear recursos?, etc.

En general, las guerras para obtener un diseño purista no conducen a nada. Hay que aplicar un poco de pragmatismo para que el diseño sea usable, consistente y se pueda comunicar fácilmente. Y sobre todo, no hay que perder de vista que REST es un estilo de arquitectura más que una lista de características a cumplir.

El “modelo de madurez definido por Richardson” y descrito por Martin Fowler echa un poco de luz sobre las cuestiones anteriores y ayuda a entender mejor los principios en los que se basa el estilo de la arquitectura RESTful. En el modelo se identifican los siguientes niveles de madurez para evaluar un servicio:

  • Nivel 0: los servicios que están en este nivel utilizan HTTP como un protocolo de transporte para codificar invocaciones de servicios remotos. SOAP es un buen ejemplo de esto porque se utiliza un único endpoint para todas las operaciones.
  • Nivel 1: los servicios que están en este grado de madurez introducen el concepto de recurso y cada recurso tiene su propio URI que permite referenciarlo y recuperarlo directamente.
  • Nivel 2: los servicios de este nivel usan los principales métodos del protocolo HTTP (GET, POST, PUT, DELETE).
  • Nivel 3: los servicios que están en este nivel retornan enlaces que permiten al cliente descubrir operaciones y obtener referencias a otros recursos. El servicio es autodescriptivo y el cliente va navegando por los resultados para invocar las operaciones.

Usando este modelo es fácil explicar que no existe una forma definitiva de hacer REST, sino que podemos elegir el grado de adherencia que mejor se ajuste a las necesidades de cada proyecto.