I\'m designing an API for a mobile app, and I hope to keep it RESTful.
API\'s are authorized using Basic HTTP Auth, however, When the user open the app for the first time, h
It's typically viewed as poor practice to pass sensitive data via an HTTP GET
request.
Password information is sensitive data and is one of the exceptions that breaks the rule that idempotent operations should be GET
requests.
Why is this an exception? Browser History and Server Logs will store GET
requests. Meaning that this sensitive information is visible as plain text in both places. So if someone gets a hold of either - then that information is now in their hands.
You should use an HTTP POST
request to pass this sensitive information to the RESTful API as browsers will not store them and servers will not log them. However, the first line of defense is to use Secure HTTP (HTTPS) to ensure that this information is protected from outsiders.
So pass this information in the body of an HTTP request to an HTTPS URL.
A good approach is to perform a GET
request for the account/profile info of the current user. and have it return the username, settings, avatar url, etc. me
is a frequently used as a shorthand identifier of the authenticating user.
GET https://api.example.com/profiles/me
HTTP/1.1 200 OK
{
"username": "bob",
"id": "xyz",
"created_at": 123,
"image_url": "https://example.com/bob.png"
}
From wikipedia:
The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client.
Because the server stores no session state from the client, your API shouldn't expose any login/logout capability: In each request you should send user credentials, and the server should validate them each time.
Check this discussion in SO, it claryfies this concept.
GET https://api.example.com/auth
With Authorization header set.
I agree with Carlos - in a normal restful API, there is no session so you can't authenticate once and then reuse the session, you would actually need to pass the credential set on every call (not ideal).
In this scenario it sounds like you would be better of using one of the openAuth (http://www.oAuth.net) - this works by authenticating when the app is first run and then generating an access token to allow access within every call (+a refresh token).
(you could argue that the access token is state - which it kind of is - however, at least it's generally significantly longer lived).