Not necessarily. If you are providing a service, you could conceivably allow clients to use POST instead of GET even for requests that do not have side effects and are idempotent.

But if you do so, any guarantee of idempotency for POST requests has to be conveyed through means that are not implicit in the use of the verb itself, so it’s not immediately understandable by all clients. Any client that does not understand the language that you use to make that guarantee explicit will not be able to take advantage of it. This, for instance, includes each and every possible kind of cache.

> does it need to use PUT/DELETE next to POST/GET

Not at all. You can implement a RESTful web service using GET and POST only.

> how badly do you rate ?action=name over http://server/actions/name

I rate both badly: URIs should name resources, not actions.

>does it require a full description of the used HTTP error-codes in all cases?
> - does it require the use of template URI’s (or even matrix uris)
> - must there be a wadl or similar formal description?

No, no, and no.

There are two problems with Amazon’s API that make it not RESTful at all:

1. Using URIs to name actions instead of resources.
2. Using GET for operations that are not side-effect free.

Granted, they can do whatever they want with their APIs, and XML over HTTP is certainly a step forward over CORBA or some such, but REST is not “just XML over HTTP”, it’s a set of design principles.

If you’re not adhering to those design principles and you’re basically doing RPC over XML (which is all fine if that’s what you want), but at the same time calling it REST, you’re going to be ridiculed once it’s obvious that you say you’re RESTful because all the cool kids are doing it, not because you “get” it.

It’s as simple as that.

There also isn’t a real list of properties IMHO or other grading system to mesure how rest-full an API really is, or is there? Where is the ReST police (and do we need it?)

What are the proper ReST qualifying rules/indicators of an API ?
- POST and GET *MUST* mean something else? or *MUST* use different URI’s if they should mean the same for the pragmatical bypass of the URI-length issue?
- does it need to use PUT/DELETE next to POST/GET, or at least the ?_method= tunneling?
- how badly do you rate ?action=name over http://server/actions/name
- does it require a full description of the used HTTP error-codes in all cases?
- does it require the use of template URI’s (or even matrix uris)
- must there be a wadl or similar formal description?
- other?

To be clear: I *do* agree that the term gets overused and easily applied as a way to indicate some geek-level-coolness, but deep down in even the most simple one of this fast growing number of ReST-API’s out there I see people officially indicating with this ReST label that their use of HTTP/XML is intentional, thought off, broader then browser-only access and most importantly: no coincidence!

Looking back at where we come from I think that such is a remarkable achievement.