I am looking for a way to wrap APIs around default functions in my PHP-based web applications, databases and CMSs.
I have looked around and found several "skeleton" frameworks. In addition to the answers in my question, there is Tonic, a REST framework I like because it is very lightweight.
I like REST the best for its simplicity, and would like to create an API architecture based on it. I'm trying to get my head around the basic principles and have not fully understood it yet. Therefore, a number of questions.
1. Am I understanding it right?
Say I have a resource "users". I could set up a number of URIs like so:
/api/users when called with GET, lists users
/api/users when called with POST, creates user record
/api/users/1 when called with GET, shows user record
when called with PUT, updates user record
when called with DELETE, deletes user record
is this a correct representation of a RESTful architecture so far?
2. I need more verbs
Create, Update and Delete may be enough in theory, but in practice I will have the need for a lot more verbs. I realize these are things that could be embedded in an update request, but they are specific actions that can have specific return codes and I wouldn't want to throw them all into one action.
Some that come to mind in the user example are:
how would I express actions such as those in a RESTful URL architecture?
My instinct would be to do a GET call to a URL like
and expect a status code back.
That deviates from the idea of using HTTP verbs, though. What do you think?
3. How to return error messages and codes
A great part of REST's beauty stems from its use of standard HTTP methods. On an error, I emit a header with a 3xx,4xx or 5xx error status code. For a detailed error description, I can use the body (right?). So far so good. But what would be the way to transmit a proprietary error code that is more detailed in describing what went wrong (e.g. "failed to connect to database", or "database login wrong")? If I put it into the body along with the message, I have to parse it out afterwards. Is there a standard header for this kind of thing?
4. How to do authentication
- What would a API key based authentication following REST principles look like?
- Are there strong points against using sessions when authenticating a REST client, other than that it's a blatant violation of the REST principle? :) (only half kidding here, session based authentication would play well with my existing infrastructure.)