11/21/11
Pizza is a Vegetable
Last week Subbu complained about Web APIs: "they are a pain". Really? Subbu gives four reasons:
1. Interfaces are bound to tradeoff special requirements of their consumers and try to stick to a common denominator
I don't get it, REST was sold to us as "easy". You can't actually give a talk or attend a talk without a guy in the attendance chanting "REST is easy". Why would you stick to a "common denominator" when you can push resource representations at will?
2. Writing client code is slow, repetitive and verbose
Subbu adds: "In one of the Java implementations I looked at, the code was over 300 lines long – that was after excluding the request making and response parsing code which was already factored into into supporting libraries. If the client needs to implement ten such use cases, you got 3000 lines of code just doing data retrieval."
I don't get it. The industry was sold on REST because, we could curl up calls to endpoints, god forbids, even GETting a resource representation directly from a browser's address field, in other words, REST is easy. We were even told that human readable documentation was enough. How in the world could we endup there?
3. API changes that the clients need don’t happen immediately. Sometimes never. The reality is that teams have their own priorities.
I don't get it. REST was sold to us because it had a "uniform interface" and good APIs URLs don't change. HATEOAS was once touted as the end of all evil, links everywhere, autodiscovery, and voila, you could fetch all you need with ease. What happened? why would you need "changes"?
4. Requests are chatty. Three hundred lines of code may not be a big deal, but making so many HTTP requests is.
I don't get it. Resource representations and the uniform interface were touted as what we would ever need and now we can only build "chatty" interactions.
Subbu is by far the most decent RESTafarian I know. Not only does he really knows what he is talking about, probably by a factor of 10, when compared to any other RESTafarians, but he is also genuinely looking for a better way to do things. But my questions to you Subbu, are:
a) was not this totally predictable 4 years ago? Who could imagine that by adding some annotations on top of Java (JAX-RS), you would end up anywhere else?
b) Isn't it time that we honestly and objectively look at (the other) "REST" (not Roy's REST)?
c) now that we are in this mess ocean of technical debt, what is the path forward ?
I stepped up to shake hands with Steve Vinoski at QCon last week, as I was getting ready to detail the program of the "Web API" track. That was quite a moment: sorry guys, Pizza is a not vegetable, no matter how many people say it or even when the US Congress says so.
3 comments
The irony is that Canapppi's metamodel abstracts these 200-300 lines of code down to 2 lines. These two lines can be viewed as a minimal contract description, but they contain enough information to generate the code. So I think this is a true metrics about how much boiler plate code there is in calling Web APIs.
Surely, we can only judge the value of something in the context in which it is being used. If our objective is to create something generic to be reused in situations we haven't imaged yet, then we don't have the luxury of specializing it for a particular domain. If the objective is to create something that's optimized for a purpose we can solve a lot more of the problem for our users and the experience will be better. There may well be no stronger supporter of domain specific solutions on the planet than me, but I also have to build reusable components, and they tend to be less optimized to any of the domains to which they will be applied.
So, where does that leave us? We have a generic object access mechanism in REST (WEB-CRUD) which is flexible but not really productive or efficient. IMHO, the productivity issue should be resolved exactly as you have done ... create an api that is domain specific and have consumers use that instead. The efficiency issue is not new to this situation and we can leverage techniques which have been used to address it in the past. I'm thinking about the database best practice of accessing information through views instead of directly. We should have three classes of RESTfully exposed artifacts from resource managers. First is the normal RESTful artifact interface. Second is a RESTful "view management" interface whereby I can CRUD views across the artifacts managed by the resource manager. Third is the "view" RESTful interface which I can use just as I would the normal RESTful artifact interface to access a view across the artifacts.
Cheers,
tc.
Comment feed for this post
