API wrapper best practices?

[Greg McCarroll]

On 25 Mar 2013, at 15:23, David Cantrell wrote:
> 
> I don't like the way that some API modules have eleventy bajillion
> objects which get in the damned way of the data.  OTOH when I do want
> objects, I *really* want them.
> 

I once worked with a company who worked with another company who had brought in IBM. And nobody had told the nice people at IBM that they wanted a CORBA interface to upload live content, you know trivial little bits of content, like oh say for example horse racing results ......... not important at all when it comes to time and bookies shops. I want to play Henry Gondorff when we make a move about this.

Anyway big blue through no fault of their own were hustled into making it all Java and CORBA so they could get this little bit of extra functionality without paying for it.

The result was a clusterfuck. It was 10+ calls to get something achieved.

So what's the lesson? User stories are the key to good API wrappers. By all means use the autogenerated stuff and put in place over the top of them helper classes to achieve things. You will never automate in place of just thinking about the problem, never. And once you have the problem understood, if its inefficient, you can adapt the base clases you have built above.

The VCS toolset on CPAN (that im also blaming Leon for) is a great example of failure, the DBI and subsequent DBIx::Class toolsets are examples where people got it right. I actually despite its tumultuous start believe that DBIx::Class is one of the best examples of taking a good foundation (DBI/DBD) and standing on the shoulders of giants in the CPAN world and delivering a world class API - that in my opinion shames JDBC.

G.