If you've set up your app with RESTful resources, you can access them
using ActiveResource. Personally, for public APIs I've shied away
from this method.
Instead, I create an apiV1 (or V2, or V3) controller, and make it
accessible at http://example.com/api/v1/\{api\_method\}\.api\. This way,
I'm able to easily work on new versions of the API without affecting
the previous versions.
For testing the API during development, I use a little library I wrote
called Bricklayer (available here: http://github.com/heypanda/bricklayer/tree/master
).
The downside to this method is that you don't (to my knowledge) have
HTTP verb access restrictions at the routing level, so you're
responsible for checking the request type at the controller level. I
usually drop in a before filter for api methods that should be POSTS
which just checks if request.post? and handles inappropriate verbs
accordingly.
If you're worried about speed... one way I've solved this is by moving
my API implementations to a separate Merb app that piggybacks my Rails
models. The downside here is that you're effectively managing two
applications, which can be a pain both on the development and
deployment side of things (though I haven't had much issue yet). To
make this work, you have to make sure your load balancer/reverse proxy
is sending requests to the right application. You can either set up
some rewrite rules to proxy based on the request, or deploy your app
to something like api.example.com and set the Merb app up as a
separate virtual host.
As far as "security" goes... depends on the app. For me, it's always
been as simple as having the client send along Basic HTTP
Authentication credentials over SSL. So if, for your iPhone app, you
want a user to be able to view his store inventory or something, you'd
just have him enter his un/pw in the client, and authenticate in The
Usual Way.
If, however, you want to prevent people from accessing the API by any
other method than the iPhone app, I'm guessing you'll want to do some
kind of handshake procedure to ensure this... which is totally out of
my realm. I'm guessing that whatever provisions you take could be
undone with some patience and a decompiler (which is why I'm against
embedding authentication information in the app itself).
M