Algunas reflexiones sobre el Objeto API.

GeneXus 17 introdujo el objeto API. Considero que va a tener un rol importante en el desarrollo de aplicaciones de los próximos años. 

En un par de charlas brindadas por diferentes empresas, he visto que lo presentan como un objeto que "agrega una capa de servicios REST a nuestra aplicación". Si bien esta es una de las funcionalidades del objeto API es una simplificación que sirve para que se entienda la utilidad, pero no me parece que sea una buena definición. 

El objeto API, lo que hace es definir una interfaz de los métodos para que puedan ser usados por el resto de la aplicación o por aplicaciones externas. 

En el objeto API, yo distingo dos partes bien diferenciadas. Por un lado, tenemos la lista de métodos/servicios expuestos, con sus parámetros de entrada, parámetros de salida y todo lo necesario para lograr procesar los parámetros de entrada y devolver la salida esperada.  Esta parte es la que tiene el verdadero conocimiento y es la que va a perdurar mas en el tiempo y va a soportar mejor las migraciones de versiones de Genexus y de cambios tecnológicos. *

Por otro lado, tiene la forma que dichos métodos o servicios, son expuestos hacia afuera, que puede ser con diferentes protocolos (hoy son REST, gRPC e Internal) y en el futuro pueden ser otros. 

Me parece que presentar los objetos API como "capa REST de mi aplicación", es una simplificación que no ayuda a entender el verdadero potencial de este objeto y puede complicar en el futuro cuando necesite cambiar de protocolo (cosa que seguramente suceda en los próximos años). 

Veo mucho potencial al uso de los objetos API en la interna de la KB, para comunicar módulos sin usar servicios REST sino llamadas internas y presentándolos como "capar REST de mi aplicación" puede llevar a confusión en los desarrolladores. 

Tener claro la potencia y el alcance de estos nuevos objetos, nos llevara a diseñarlos de forma mas desacopladas y poder migrarlos de forma mas fácil en el futuro. 

Es muy probable, que en el futuro tengamos otras formas de exponer los servicios (AsyncAPI, GraphQL, etc) por lo que es bueno saber que esto puede pasar y programar en consecuencia. 

* Asociado a la definición de un metodo o servicio, me gusta tener un conjunto de pruebas unitarias del mismo. Son parte del conocimiento que debe tener la aplicacion, pues son los requerimientos ejecutables del metodo o servicio. 

Comentarios

  1. Que interesante, no he visto mucho de este nuevo objeto ¿Se puede definir un API solo con "internal" sin exponerlo como REST o gRPC? Es decir si no lo van a usar externos, solo desde mi propia KB.

    ResponderBorrar
    Respuestas
    1. Si, se define el objeto y ya se puede usar como interno. Te recomiendo que lo pruebes. Las aplicaciones quedan mucho mejor modularizadas.

      Borrar
  2. Una consulta.
    El objeto API, esa capa rest en mi aplicación ¿De por si actúa como una capa de seguridad?
    Es decir, si la aplicación externa está expuesta a internet y la aplicación del backend, en la que expongo estos servicios tiene información delicada y se encuentra en una red privada, si al consumir esta API que se encuentra en la misma aplicación (privada) que tengo la conexión a la Base de Datos ¿No es una vulnerabilidad? o es mejor tener un Api Manager "en medio" de la aplicación Frontend y backend.

    ResponderBorrar
    Respuestas
    1. Desde el punto de vista de seguridad y administracion de uso de la API, es mejor tener un APi gateway o manager para administrarlo.
      Agrega costos, es un poco mas lento y complejo. Como todo en seguridad es un comptomiso que se estudia caso a caso en cada aplicacion, dependiendo que informacion maneje.

      Borrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Aplicación monolítica o distribuida?

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.