Joaquin Copete bio photo

Joaquin Copete

Skilled and experienced Middleware architect, with 10+ years experience in different integration projects, both internal (EAI, ESB) and external (B2B). Problem solver with ability to build questions that uncover business needs, and possesses the ability to build and maintain business relationships with decision makers and influencers.

Email Twitter LinkedIn

An API developer has usually different concerns than other roles might have in the API economy as any API developer can create those assets belonging to the API product that are usually consumed by third parties. Those third parties might be developers creating internal applications, or developers creating external applications and new sources of revenue for the company.

The approach that an API developer might take is to create such APIs as if any of the potential API consumers were external, what leads us to the main topic regarding APIs as interface to hide complexity.

Taking into on consideration the assets that a certain company might already have, there is a straight forward path of getting them as they are and expose them as APIs. Then we would think that API Developers life is easy, and is only a Database to REST, or SOAP to REST mapping. But there is a longer trip that might be much more interesting, doing business as usual will lead us to take the usual results. On a Domain Design Driven approach API developers could be fed with challenging APIs that might expose business relevant features, and not only technical assets.

In this Domain Design Driven approach, API Developers might be reusing some of the existing assets, but creating and changing others ( services, processes ) so much more interesting features are exposed.

In the last few years lot of interfaces has been built around huge files exchanged between companies, there were some reasons for this like batch processing, and cost by transaction fees. With API revolution (together with internet, security) this model might be changing and might be improved, so the request might be processed in the moment and the person in the other side of the line is getting a proper response in the right moment. I think in processes like batch payroll, invoice, order, just for commenting on some. A bunch of information is sent, and bunch of statuses are sent back.

It’s true, the new model might be challenging for some API Developers, but sooner or later if you don’t do it, someone will do it instead of you.