I have only just started mussing over the very same idea. In my
thinking the URLs would be much more readable. The core user resource
would be something like http://example.com/users/{uname} To use this
for authentication purposes, an application would receive credentials
from the user, and GET a URL like the following from the RESTful
authentication service: https://example.com/users/{uname},{passwd} (note
the use of SSL). That could return the same resource as the previous
URL, but more usefully could return, say, a SAML token appropriate for
the asking application.
Of course, one should not just assume that the proposed URI scheme will
last forever, so a better solution is for a client to first request a
form (from a "cool" URL), e.g., http://example.com/authentication_form.
That form will contain the necessary fields to populate and (assuming
it's an HTML form) will allow you to construct a URL. However, in this
case the URL would end up looking something like this:
https://example.com/users?uname=placey&passwd=sekrit. Which isn't as
pretty as the other version, but serves the same purpose and uses a
standard recipe for link construction.
Pete
JC wrote:
I am trying to develop a Restful login system. Using a web service I want to
identify a user based on their user name and password, but I am not sure the
best (Restful) approach.
I would like to avoid the RPC approach of calling an authenticate method,
passing in a user name and password.
The best (Restful) solution I have come up w/ so far is to have the URL
HTTPS://www.example.com/user/{user}. The {user} placeholder would be the MD5
value of the concatenated string of user name + password.
Ex.
User name: MyName
Password: MyPassword
{user} = MD5(MyName+MyPassword)
If the user is found return a XML representation of the user, if not return a
404 error.
Thoughts, comments, suggestions?
