¿Por qué lo llaman API cuando quieren decir servicio?
Últimamente se utiliza muy fácilmente el término API REST, cuando realmente queremos en un servicio que ejecute una acción sin más y nos liamos la manta a la cabeza para encajar lo que necesitamos con el término de moda.
Un API Rest trata de manejar recursos que tienen un modelado que no son puros verbos, sino que representan conceptos de negocio, normalmente son sustantivos (en singular o en plural), aunque alguna vez nos vemos obligados a diseñar verbos como sustantivos para encajar acciones determinadas que no tendrían cabida dentro de una lógica de recursos puros, pero están más o menos moralmente aceptadas.
Pero en otras ocasiones, solamente queremos un verbo, por ejemplo, sumar, contratar, convertir, etc. Son acciones, son verbos que no deben cuyo resultado no persistir en el tiempo, queremos unas funciones puras, que reciban unos parámetros y devuelvan un resultado sin acciones colaterales.
Pero con la APItitis actual, nos sentimos en la obligación crear un API a toda costa y eso no es sano porque desvirtuamos lo que realmente estamos diseñando.
— Pero es que yo quiero utilizar REST — dijo el desarrollador de turno.
— ¿Por qué? — pregunto yo
— Porqué quiero usar JSON y verbos HTTP
¡¡¡Acabáramos!!! REST es un estándar que usar URIs como recursos y los verbos pero que sea REST no significa que sea API.
Hoy en día están los servicios serverless, acciones que se invocan que se levantan cuando el cliente requiere la operación y se apagan para ahorrar (tomad esto como una licencia poética) pero que la forma de actuar puede ser perfectamente con JSON y verbos HTTP.
Que quiero decir con esto, que NO os compliquéis la vida si queréis hacer un servicio, hacedlo, no necesita ser SOAP, podéis hacerlo REST pero llamadlo por su nombre SERVICIO REST un API conlleva un nivel más que en ocasiones entorpece en lugar de ayudar.
¿Quieres seguir leyendo? Aquí debajo tienes algo que puede que te interese.