• Post Reply Bookmark Topic Watch Topic
  • New Topic

rest guidelines

 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
there are several principles here that I'm completely don't understand, here's one:

A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.]


my take is that if it's restful, then it shouldn't only expect HTTP or FTP as the only means of communication. But the second sentence really confuses me:
1. "though its successful mapping to a given protocol may be dependent on the availability of metadata" --> which mapping? what metadata?
2. "In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification" --> don't even know what this means.

Thanks
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's a bit difficult to talk about these, because even though REST is defined without reference to any particular protocol, it was designed with HTTP in mind, and to my knowledge no implementations using other protocols exist. So that's a bit different from SOAP, where implementations using other transport mechanisms -like raw sockets, mail, messaging- are readily available, although rarely used (see here for the Apache Axis2 SOAP stack).

#1: "Mapping" means how a REST API is implemented using a particular protocol. For example, REST uses HTTP methods to indicate the kind of action to be taken (GET, POST, PUT, DELETE etc.). FTP has no notion of a "method", so some other way would have to be found to express the same - maybe using FTP commands. That would be an example of metadata.

#2: The scheme is the first part of a URI - the part before the colon. http, ftp, mailto etc. are frequently encountered in the wild. Here it's important to differentiate between a URI and a URL. All REST APIs I've ever encountered use the URL for identifying the resource - in effect, using the URL as a URI. That makes a lot of sense in order to keep things simple, but it doesn't have to work that way. It would be possible to come up with a REST API that uses a scheme of "david" for identifying resources, but then you would additionally need a URL to access it, because no client software knows how to handle the "david" scheme (whereas a browser does know how to handle the "http" scheme, amongst others). So this sentence is relevant only for a REST API that separates identification from access - no such API exists to my knowledge.
 
David Spades
Ranch Hand
Posts: 348
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
as far as I know, one scheme always maps to exactly one protocol, so we can use these two terms interchangably, yes? or am I wrong?
when we want to request a resource, and we want to use our own "myscheme" scheme, then this would mean that being restful, API must be able to locate the same resource with both URL: myscheme:abcd.com/rsc.xxi and ftp:abcd.com/rsc.xxi.
Is this what this quote was trying to convey?
thanks
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
as far as I know, one scheme always maps to exactly one protocol, so we can use these two terms interchangably, yes?

For URLs, yes.

when we want to request a resource, and we want to use our own "myscheme" scheme, then this would mean that being restful, API must be able to locate the same resource with both URL: myscheme:abcd.com/rsc.xxi and ftp:abcd.com/rsc.xxi.

No. Note the distinction I made in my last post between "identifying" a resource (what you use a URI for) and "accessing" a resource (what you use a URL for). URLs and URIs are two different things, even thought they often look similar. That statement talks about URIs, not URLs - if an API is accessible via a http URL, then it does not follow that it is also accessible via a myscheme URL. If a resource is identifiable via an http URI, then it should also be identifiable via a myscheme URI - that's how I read that statement. I have not encountered a REST WS that uses URIs that are different from their URLs, though, so the whole thing is academic, IMO.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!