This is the third fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.
What can you do that would make your product more extensible, more configurable, easier to put into the ecosystem you are trying to serve? I always explain APIs as a sort of Lego connector between a given piece of software or data, and anything else someone chooses to stick on it. Make your APIs standard and DOCUMENT THEM WELL.
What makes you so sure this API will always be internal?
On a recent contract, we started to create APIs for our internal services. We bodged them together in a really ugly way, with names that only made sense internally, based on dead products we didn’t release. I argued that it would be better to build them correctly, but obviously I didn’t argue enough, and when I left, they were having to rewrite the whole API call structure because an external client had requested access it.
Don’t make future-you mad.
Make future-you happy by designing your product to consume APIs. That way when you get a sudden request to provide APIs for a customer, you’ll know that they work because you’ve used them yourself.
This blog post is part 3 of my Seven Fights series. You can hear me give this talk TOMORROW at The Lead Developer in London (June 22-24) or at SpringOne Platform (August 1-4) or Abstractions (August 18-20).
O'Reilly Software Architecture/Velocity
The Lead Developer London
Full Stack Conference London
Texas Scalability Summit