I’m just getting into using REST and have started building my first app following this design model. From what I can gather the idea is to build your service like an api which your website itself is a consumer of.
This makes sense for me since my web app does a lot of AJAX calls, however it seems a little wasteful to authenticate each request to avoid using sessions. Is this just something I have to accept as part of the REST design process?
Also, making ajax calls works fine, but say, I need to just show a view of the users profile, does this now mean I also need to make a curl call to my api to pull this data. At this point I know I’m working internally so is authentication even required?
Some remarks:
While you could set up your whole application to have a REST interface, you should set it up to still be able to call it internally. Calling it from HTTP, and getting results back by HTTP is only input-processing, and output-rendering. So, if you seperate those concerns you get a flow:
input-processing -> method call -> data return -> data rendering. Shaving of the first & last bit, what do you have left? A function call that returns data, which you can just use in your code. Seperate functionality to translate an ‘outside’ function call into an ‘internal’ one, and render ‘internal’ data into ‘external’ (xml, json, html, whatever you desire), makes your app efficient, and still fully REST capable.Authentication is needed if you allow outside calls, even if you don’t ‘tell’ other users data can be retrieved a certain way, it is still easily discoverable. I don’t know why you wouldn’t want to use sessions for this authentication (which most likely happens in forementioned translation from an ‘outside’ call to an internal one. I would not make ‘not using sessions’ a requirement, but there is no reason you couldn’t allow several methods of authentication (session, re-authentication on every request, tokens, etc.).