From my last comment on the attributes=nil post:
Whilst I love repond_to, does anybody out there actually provide their public API by just pointing the world at their controllers?
Can you provide useful, robust and human error handling just using this, and is there a perfect 1:1 mapping between browser request params or do you end up having to mung params and litter if
request.api?around various actions?
Not to mention a few others; API versioning, reflection, and differences in caching.
Don’t get me wrong, I love respond_to, but it is most useful when you’re assuming the controller part acts exactly the same regardless of how the request arrived.
Those who’ve implemented a complete, documented and supported API for their Rails app: did you route through your existing controllers and use respond_to, or did you have separate controllers and make sure your model was sexy enough that the controllers were trivial anyways?
Archived comments
Comments were previously allowed on articles. Though no new comments are being accepted you can see the old comments below.
-
Existing controllers and respond_to, no separate controllers for https://score.boomtestuitgevers.nl/api.html
-
At Blinksale we do it that way — controllers simply represent resources, and respond_to differentiates between representations. (http://www.blinksale.com/api)
-
Existing controllers and actions.
(The project is not publicly available, so I can’t point to it)
-
thanks guys. Very interesting to hear feedback from real apps, and that Blinksale ruby client is sweet. Don’t believe I hadn’t seen it until now.
I’m assuming the
respond_toit’s worked well for the three of you?Secondly, to generate the XML responses did you find the standard
to_xmluseful enough (with:onlyand:include) or did you have to overrideto_xml/ use your own builders? -
In this application 2 out of 18 models override to_xml.
-
Cheers Thijs! v. interesting…