API Building

Scroll Down

Interoperability is a key element in software today. I'm often shocked when I read about how many big organizations (here in Denmark, typically governmental organizations) that still try to build the famous 1-big-system-that-does-it-all. And those projects always fail. Even if they 'succeed' it's usually still a failure cause the system is outdated the moment it reaches production.

The trick to success is as always: divide and conquer. Use the best software for each task - and ensure the systems can work together. This is where API's come into play, and I've done my fair share of them. I still find it intriguing though. An API is really just a UI for developers implementing solutions based on software products - and making the ideal API can be quite tricky. There are so many choices to take.

I've build and used many API's. Both assembly based, but today, more often than not - it's REST based. And some of the best systems I have worked with have started with an API first approach - and then build a UI on top of the same API that other developers can use to integrate. This is so much nicer than the API's that are retrofitted on top of an already existing system to get a checkbox in the "API" row of the RFP...But I suppose we've all been there.