3 ms·

I've tried to accomplish a REST API + JS client on a few of my projects, but where I get hung up is session handling. What I've ended up doing is writing the R

• pilif 16y ago
  you shouldn't need to do session handling if you are going REST. Rest is all about not having state. If you need authentication, authenticate on every request. If your request needs some additional info to give a response, pass that information in when sending the request. It's really a different paradigm and sometimes it can get really painful to move away from the way of thinking that we are used to.
  • roder 16y ago
    I realize that you don't want to maintain state in a REST api. It's not that it's painful to do something I'm use too (ie: session handling), it's just its painful implementing. My point was that I totally agree with the notion of a REST-based service, but it's easier from an implementation perspective to have have web-heads for views (static files, session handling, etc) that interact with the application (REST) server.
• necubi 16y ago
  How I've done it is something like this: (1) Client sends auth info to backend server (2) Server sets auth cookie on client (3) Every request goes through a proxy written in Ruby/EventMachine which either just passes through the request to the backend server if requesting something public or first checks that the client's auth cookie is valid if its requesting protected resources. This certainly isn't as simple as it would be in a server-side framework, but otherwise it works pretty well.