It is common to see support for GET and POST and not PUT and DELETE.
To maintain the integrity of the four HTTP methods, we suggest you use the following methodology commonly used by Ruby on Rails developers:
Make the method an optional parameter in the URL.
Then the HTTP verb is always a GET but the developer can express rich HTTP verbs and still maintain a RESTful clean API.
I think you shold take a step back and ask *why* you want to do that. What kind of client do you envision that can't use some of the HTTP methods?
The reason why is our old API, which isn't RESTFul at all: "GET /createNewCats.do" and "POST /createNewCats.do" does exactly the same thing.
Today, I'm developing a new API, which I'd like to be RESTFul. My problem is: I'd like to make the functions of the new API accessible to the users of the old API (who refuse to use HTTP methods) while keeping the new code clean.
The dirty solution would be to have "POST /dogs" for new users and "GET /newDogs" (which would be the RESTless clone oh the previous) for the old users.
A little cleaner solution would be the possibility to override the method to make the new API more flexible: "POST /dogs" for new users and "GET /dogs?method=post" for the old ones.
Now I would like to know which would be the better way to implement this "?method=post":
- Maybe some way of overriding annotations?
- Ready to use solutions?
- Maybe some examples?
- Other ideas?