4 ms·

I was following, until I got this "No out-of-band knowledge should, therefore, be required beyond understanding a media type that the resource can provide. From

by vinhboy 17y ago

I was following, until I got this "No out-of-band knowledge should, therefore, be required beyond understanding a media type that the resource can provide. From there, it should be possible to follow relations provided in “hypertext” context of the representation to “transfer state”, follow relations, or perform any necessary actions." -- can someone translate that? I don't understand it.

loup-vaillant 17y ago
Out-of-band knowledge is prior knowledge. Typically file formats or protocol specifications (whether they are standardized or not, widely used or not). The first sentence of your quote say that all prior knowledge should be about media formats (like the html specification, microformats, the PNG image format…). From there, the medium itself should provide enough clue for the client to go on. For instance, anchor links in html says you can GET a resource at the specified URI. Other media formats could provide other clues. To sum up, the only things you can specify a-priori are media formats. URIs and protocols should be interchangeable, so you can update and deprecate them. I think the main goal of REST is to concentrate coupling on media formats alone. Hopefully, most media formats are (or will be) standardized, effectively reducing coupling. Basically, REST architectures are for the long term.
- DougWebb 17y ago
  Also, a URL for the root of your service should be sufficient to find every resource that the service provides access to, and every method that can be used with those resources. The example is a website; from the home page of a website you can reach every other page of the website by navigating through hyperlinks and form submissions. Another example drawn from the article: if the blog posting service provides each post under a uri like /posts/{post-id}, the client of the service shouldn't have to know the uri structure. Instead, /posts/ should be a resource, and it should contain hyperlinks to all of the /posts/{post-id} uris that are available. There would probably be some metadata about each one as well, such as a title, to enable clients to figure out which one they want to follow.

by vinhboy 17y ago

loup-vaillant 17y ago

Out-of-band knowledge is prior knowledge. Typically file formats or protocol specifications (whether they are standardized or not, widely used or not). The first sentence of your quote say that all prior knowledge should be about media formats (like the html specification, microformats, the PNG image format…). From there, the medium itself should provide enough clue for the client to go on. For instance, anchor links in html says you can GET a resource at the specified URI. Other media formats could provide other clues. To sum up, the only things you can specify a-priori are media formats. URIs and protocols should be interchangeable, so you can update and deprecate them. I think the main goal of REST is to concentrate coupling on media formats alone. Hopefully, most media formats are (or will be) standardized, effectively reducing coupling. Basically, REST architectures are for the long term.

DougWebb 17y ago
Also, a URL for the root of your service should be sufficient to find every resource that the service provides access to, and every method that can be used with those resources. The example is a website; from the home page of a website you can reach every other page of the website by navigating through hyperlinks and form submissions. Another example drawn from the article: if the blog posting service provides each post under a uri like /posts/{post-id}, the client of the service shouldn't have to know the uri structure. Instead, /posts/ should be a resource, and it should contain hyperlinks to all of the /posts/{post-id} uris that are available. There would probably be some metadata about each one as well, such as a title, to enable clients to figure out which one they want to follow.