On 13/12/06, Gordon Sim <[EMAIL PROTECTED]> wrote: > > > > > > > Steve Jones wrote: > > > > > > On 13/12/06, Gordon Sim wrote: > > > > > > > > > Steve Jones wrote: > > > > > > > > > > > > So what is the implementation of REST called? > > > > > > Sorry, I don't understand the question. As I understand it REST is an > > > architectural style i.e. a named set of architectural constraints. A > > > system may or may not conform to those constraints. > > > > But there must be a way of turning REST into implementation, like the > > way when people talk about WS-* and technology I call it Service > > Oriented Development (SOD IT). What ever the ROD approach is it > > should have things such as naming conventions. > > I don't quite understand your terminology. A system may conform to the > REST style (if it conforms to the constraints that make up that style); > you can create a RESTful system by ensuring that you conform to its > constraints.
SOA is an abstract architecture focused around business services (where names are critical), ROA is a software design style (IMO) focused around resources (where names are critical) MIME types (where names are critical) and HTTP. > > That system may (or may not) also conform to some explicit naming > convention for URIs. So what I am saying is that it would be _sensible_ for there to be a formal naming convention to help increase the network effects of REST. > > > > > I'm really struggling > > > > to understand why REST people dislike having decent names for URIs. > > > > > > The REST people on this list seem to me to have shown no 'dislike' for > > > 'decent names', they have just pointed out that isn't a characteristic > > > of a RESTful system. > > > > And here is the challenge I have, for me a decent RESTful system > > should have decent URI names. > > Fine. If you come across a system that does not use 'decent' URI names > you can say the system is not in your view 'decent'. But you can't use > that alone to say it is not RESTful. And I will make assumptions as to its quality and the ability of the people who wrote it. > > In the same way I could say a piece of Java code is not 'decent' if it > doesn't conform to my notions of style; I could go further and say it > violates the Sun coding style for Java. But I can't use that to say it > violates the Java Language Specification. (This is a very loose analogy > of course, so don't follow it too closely!) And I will reprimand the person who does it. > > > Given the importance placed on URIs in > > the REST paper and the importance of names in general to people I > > think its an over-sight. I'd say in a SOA the names of services are > > 100% an architectural element as they represent a key link between the > > business and the system, and I'd argue in REST that resource names are > > again a key link, and given that the URI is the manifestation of that > > resource (i.e. it is the "real" name of the resource) then the two > > should match. > > Correct me if I am wrong, but I don't recall WSDL including an explicit > naming convention that must be followed e.g. for service names. That is > perfectly sensible in my opinion. WSDL specifies an interoperable format > for describing a service. A naming convention would be a separate issue > as it wouldn't affect interoperability at the level WSDL addresses (it > might however help make service names easier to remember or more > intuitive or whatever). And its to that latter point that I'm addressing this, a convention has grown up around WSDLs that names should be sensible. There hasn't need to be a request for this on the basis that everyone has just been pretty sensible. > > Hopefully this at least clarifies my opinion and we can then perhaps > agree to disagree. I am not arguing that meaningful URIs are not > valuable; I just think that any formal naming convention is a *separate > issue* from the description of an architectural style. Fair enough, as long as we agree they are valuable. I just don't understand why classifying a system that uses non-sensible names as "crap REST" would be an issue. >
