On 27/07/07, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > On 7/26/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > On 26/07/07, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > On 7/25/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > And DELETE doesn't mean delete the *thing*, it means delete any > > > > > representations of the thing. All things have representations, so > it > > > > > makes sense for the same reason GET makes sense. > > > > > > > > But not for those resources where its illegal (and I mean illegal) to > > > > remove them (think Enron and shredding). It is not always valid to > > > > delete something, either in terms of the physical thing or a > > > > representation of it. As more and more elements are electronic only > > > > the resource is often the only reference of its existence. > > > > > > If it isn't allowed, then a 403 Forbidden response can be returned. > > > > Which means that the call isn't valid. i.e. that resource does not > > support those calls. It could be argued that attempting to delete > > something that cannot be deleted is a bad request (400) rather than > > just forbidden. Equally it could be argued that a 501 (not > > implemented) would be a valid return as the resource doesn't implement > > this functionality. > > No, it's just a permissions problem. If you tried to call > getSensorValue() on a sensor but received a permission fault in > return, would you say that wasn't "valid"?. It's not like we're > trying to call feedDog() on the sensor, which wouldn't make any sense.
But I thought we'd already agreed that for some things a "DELETE" doesn't make sense? It isn't about permissions (as that implies that someone else could do it), its actually that there are certain things where a DELETE request doesn't make sense (e.g. DELETE Energy). > > > > > If the argument is that even if the operation isn't valid that it is > > > > RESTful because its available to be called (and fail) that doesn't > > > > sound overly uniform in terms of the semantics of the operation. > > > > > > Yes, that's exactly the argument. I don't understand your problem with > it. > > > > I don't have a problem. I was just pointing out that REST resources > > don't have to have a uniform interface as they are not compelled to > > implement all of the methods, they are perfectly allowed to implement > > only some of them. Yes you can make the same call as a client, but > > the interface on the resource itself could be less than the PUT, POST, > > GET, DELETE set. Each resource does not have to support all four, > > No, of course not. But if a method isn't supported, 501 can be > returned; the interface itself accomodates the lack of an available > implementation of a method on a particular resource. The method still > makes sense on that resource. Makes sense but isn't supported? A bit of a contradiction in terms there surely? Either it makes sense (and therefore should be supported) or it doesn't make sense and therefore isn't supported. > > > The argument that multiple reads (by type of "thing") is not uniform > > seem (to my mind) a trifle odd as well as it implies that you must > > reduce the instructions to their bare minimum rather than them having > > uniformity being the important element. PUT(null) could be argued to > > be equivalent to DELETE, but I wouldn't argue that because I can > > achieve things in two ways that DELETE is therefore not RESTful. > > If you could successfully argue that, you would be right. But > PUT(null) doesn't mean the same thing as DELETE, for the same reason > the empty string and the null string are not equivalent. Why doesn't PUT(null) mean DELETE? What stops a uniform convention of PUT(null) meaning delete? I don't see where empty v null comes into it, empty is a blank assignment which means the resource exists, null means it no longer exists. All that has to happen for PUT(null) to be accepted as the way to remove a resource is for it to be the stated convention, in the same was DELETE is currently accepted to be the way. > > > > > The bit I find strange is how an interface can claimed to be uniform, > > but the resources don't have to implement all of the interface. > > Another way to look at it is that what individual resources do or > don't do is an implementation detail, and therefore separate from > interface. Which is fine, and indicative of the fact that REST provides a standard mechanism for shifting information between producer and consumer but the real operational interface (i.e. what actually happens) is the responsibility of the implementation and it is that which the consumer is actually interested in. > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Coactus; Web-inspired integration strategies http://www.coactus.com >
