Hacker News Reader

Cookie-based authentication is generally only applicable to the browser interface. From my point of view where REST really shines is at the API level. HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) is good at the API level where you send your credentials with each request.

View on HN

> HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues )

You know, with all the little browser-chrome experiments that have been going on lately, I'm really surprised that no one has tried to make HTTP-authentication-based login/logout/account management as painless as HTML-served variants. I'd imagine that it would couple with the little "lock" icon in the URL/status bar, making it have four states instead of two: "insecure, secure, insecurely logged in, and securely logged in" where clicking on it brings up a menu to both view credentials and change your password/edit profile/log out/close account/sign up/anything else browser makers want to implement. (They could be distinct, of course, but I like the idea of making "insecure" look scary so that users would be deterred from sending credentials through it.

What if you have to serve both interactive users and automatic clients? Would you use the url structure for both or would you have a separate api structure?

Reply on news.ycombinator.com