The International Image Interoperability Framework (IIIF) has put a draft API for the delivery of images via a standard http request. It supports information requests as JSON or XML as well as image requests.
One of my first reactions is that it sticks to the letter of RESTful interfaces while doing things that would be more sensibly be expressed by URL parameters. The following are offered as example URLs:
http://www.example.org/image-service/abcd1234/80,15,60,75/full/0/native.jpghttp://www.example.org/image-service/abcd1234/pct:10,10,80,70/full/0/native.jpg
That’s harder to understand than something like x=80&y=15&w=60&h=75.
A service must specify the level of compliance it provides, which may be different for different images; for instance, JPEG2000 images might be scalable but GIF images not.
If widely adopted, this API could simplify access to images spread across multiple repositories. I’ll be looking at it more carefully as soon as I find the time.
Mad File Format Science 
My thoughts were the same as yours as soon as I read the spec, but to me, your approach is the RESTful approach. The resource is the image, the parameters form part of the query string to reduce the result. Perhaps it is me interpreting REST incorrectly, but I certainly agree that your method is the more readable
I’ve been under the impression that true REST excludes URL parameters, but I don’t know of anything that actually says so. So perhaps you’re right.
Gary, Dan–thanks for these comments. Please don’t be shy about submitting them to the iiif-feedback@googlegroups.com email address.
I sent more detailed comments to that address yesterday. A couple of other items I mentioned in that email: (1) A “thumbnail” size, whose exact dimensions are determined by the server, would help efficient thumbnail delivery. (2) Using the term “full” in two different ways is an invitation to encoding bugs. Using different terms for full region and full size would be better. A co-worker suggested the latter to me.