On 7/26/07, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > Mark Baker wrote: > > > > > > On 7/25/07, Gregg Wonderly <[EMAIL PROTECTED] <mailto:gergg%40cox.net>> > > wrote: > > > The number of functions is limited based on the address range you are > > refering > > > to. I'm not sure how you can summarily conclude that the HTTP > > definition of GET > > > is somehow the only valid definition of such a RESTful operation. > > > > It's not the only valid definition of a RESTful operation. There are > > many possible RESTful operations. But GET is uniform and therefore > > RESTful. > > > > How you know whether an operation is uniform is not, is to ask the > > question "Does it make sense to invoke this operation on every > > identifiable thing"? Consider "read coil status" from MODBUS. Does > > it make sense to invoke that operation on registers? Of course not. > > Therefore it isn't uniform, and not RESTful. > > The MODBUS protocol differentiates different resource types because the > returned > results have different types. The use of a particular type of READ has, > implicitly a particular type of "allowed" results, confining the system in the > same way that mime-types do for HTTP. If there were no mime-types in HTTP, > would there be a single GET? I think not.
I understand. I'm just saying that's not uniform. > > > GET means "retrieve me a representation of the identified thing". > > Everything can be represented, therefore it's uniform. > > Unless I'm misunderstanding something, you are not considering the issue of > allowed mime-types sent with the GET which can make the GET fail because a > particular type of result can not be sent. The use of multiple types of READ > operations in MODBUS is equivalent to an additional specification of > MIME-TYPE. It's functionally equivalent, yes. It's not architecturally equivalent though. > > The coils have a particular address range (resource name) and the status > registers have another particular address range (resource name). You are > still > convinced that the NAME of the operation is the only thing that makes the > delination of uniform or not. I think that's a bit short sighted. Not so much the name of the method, but its meaning. It's meaning has to be relevant to all things. That's by definition, you're not allowed to disagree with it! 8-) > If the name is all that matters, than does HTTP need anything more than POST? > The semantics of GET, PUT etc. provide more specifics, but are those names the > only way that those semantics could be selected? Clearly POST could have a > single expected header-component to that could provide the same semantic > indication and specification based controlling function. Sorry, I don't follow. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
