So I’ve recently been building in an API to my application. I’ve looked
at it in a number of ways to see how best to approach it. I’m on edge
rails now to evaluate the RESTful stuff, too.
In general, I like the REST URLs. It’s nice to have a convention.
But I’ve seen a bit written up about how nice it is to have the API and
“non-API” code wrapped neatly into single actions within the controllers
and use “respond_to” to figure out how things should be handled. I have
started down this road to fully get a feel for it and I’m not sure I get
it yet.
I can see how this would be useful for relatively simple apps like blogs
and todo-lists where you have basic presentation. But in more elaborate
apps, you end up with presentation that varies considerably between the
API and non-API views.
Consider, for example, an online st0re. When a human asks to list
items, the controller may call up several associations before
presenting. The items are there, of course, but also there might be
related items, price quotes for the items elsewhere or in different
quantities, item stock, and so on.
Basically, for all but the simplest actions, your handling is quite
different whether you’re presenting to a human or another program. HTML
presentations have redirects, flash, session handling, and so on. The
API presentations are pretty simple and straightforward. The added
overhead of the “respond_to” handling kind of messes up my controllers.
So for me, I feel it is better to keep the API separate. I can test it
separately. I can see it separately. I can more easily wrap my head
around the methods provided and the data offered.
But the jury is still out for me. Is there something I’m missing here?
I’m really interested in hearing from folks that have engineered larger
applications with APIs.
Jake