I'm trying to create a RESTful web service in PHP.
According to Roy fielding, communication betweenn client and server must be stateless in nature.
So is storing login information, as in the currently logged-in user's username, in the PHP $_SESSION variable the wrong way to go, since it means storing session state? This is for the purposes of allowing access to a user's private data.
Is using cookies to keep track of logins against REST principles? Or is it not something that's too important?
If you want to be hard-core about the stateless aspect, which might be important in certain systems, you could send the user's credentials on each request. This lets you authorize access to certain resources and verbs without creating 'state'. See the documentation for Amazon's S3 service, for example.
I'm tempted to say that other uses for sessions, like a shopping-cart, for example, create a real emphasis on state that goes against REST.
HTTP is stateless, thus any use of a session goes against the design of HTTP (and most of the design and security problems on the web today stem from this).
To achieve true stateless authentication, use the WWW-Authenticate and Authorization headers with your API, or upgrade the API to be exposed over HTTP+TLS (https), issue each API user account with a X509 Certificate which identifies them, then request it is sent with each API call (you can then identify them by the public key which you save against the account as an API key).
ps: always worth reading in context, chapter 6 of Roy's dissertation is invaluable but often ignored for that single chapter 5 REST.
can expand the answer if you need it :) expanding..
The Authorization request header and WWW-Authenticate response header are standard HTTP Headers used for Challenge Response Authentication, the two common and standarized methods for use with these headers are Basic and Digest Authentication. If Authorization credentials are sent with a request you process to allow access else fail with the appropriate status code, or issue a challenge using the WWW-Authenticate response header, the flow is the same as form based authentication, but it works at a RESTful HTTP level instead, and should be used to verify each request rather than setting up a session (like most do with form based authentication).
The HTTP+TLS/x509 method to which I refer is commonly known as Public key authentication, again it works at a protocol level rather than application level and is natively supported. In short the client has an private key + certificate + public key on their side, when they connect to you the certificate (which includes the public key) is sent through to the server, you then read the details from the certificate (if you want) and use the public key to authorize them, if you recognise it you let them in. This is more secure because it uses the HTTP+TLS stack where everything is encrypted and the connection is between client and server with nothing in between, and primarily because effectively the 'password' is in two parts, a private key which never leaves their machine, and a public key which does, together they form a key pair.
The PHP manual has a nice section on HTTP Authentication with code (for the headers method) and all the functions needed for HTTP+TLS/x509 are also in the manual (with examples in the documentation, but split over the various functions).