For logging in. No. It's not the cookies that are the problem here, but the fact that such systems create stateful sessions which isn't what rest is about. There are some ways, for instance, using http authentication systems like http basis, digest, or more advanced systems like oauth(2) that can be used to let people "log in" into an API without loosing the stateless character of REST.. I will add this this to the recipe (hopefully) soon :)

I've chased the RESTful login/authentication around the web off and on when thinking about REST apis. It seems to boil down to two main approaches.

1 - follow the AWS API models, with a signed request using a private secret known only to the user and the server-side. You can see the S3 docs on RESTful auth using this approach. Also seems to recommend doing this over SSL.

2 - use SSL and send a userid/passwd or authentication key on each request.

In general, cookies are regarded as one of those "makes it not restful" type things.

I'd love to hear from HN'ers on how they handle RESTful authentication, particularly for projects where they are providing an API that is primarily consumed by a web app or other tool they implemented for users and have used RESTful api design as a design viewpoint.

Short answer: Yes, you can use cookies, but not all systems support that (eg mobile apps).

Here's what I do for that case: Create a /sessions endpoint and POST to that when you login. The session resource will include a token of some sort identifying the session securely. The client can then authenticate to the API by passing this token via an HTTP header.

I'm trying it out where you send login json ('{"username": "foo", "password": "bar"}') to a special view, e.g. /api/v1/users/login/, and in return the client gets the user model and other related data in the response (assuming creds are valid). We also use a sessions to maintain state.