Semantic Web: Resource-Oriented Architecture Patterns for Webs of Data

Resource-Oriented Architecture Patterns for Webs of Data:

Start on page “1” (about 60%).

"Whatever domain we work in, we can imagine translating the data elements we care about into named resources:
http://example.com/account/user/jsmith,
http://example.com/employee/id/12345,
http://example.com/order/id/101-276-32, or
http://example.com/product/id/upc/800314900528.
These names represent good, long-lived, stable identifiers for these disparate domains."

"Avoiding data extraction, transformation, and loading (ETL) steps reduces the burden of having multiple copies of our information repositories. We can achieve the goals of a Master Data Management solution while simultaneously avoiding the unnecessary limitations of a prescribed format."

"When you point your browser at any random website, it does not “know” anything. It issues a standard, semantically constrained verb, called GET, to a named element and responds to what comes back. “Oh, an HTML document! I know how to parse that.” or “Oh, a plain text file, I know how to display that.” It is reactive. It does not know. Knowledge is a form of coupling."

"The client does not know what it is going to get, it reacts to what is returned. It knows how to parse standard types. And from there, it discovers what options to present to the user (if there is one)."

"The media type should be designed to support hypermedia links. This should identify the resource itself, as well as its related resources. Clients will be able to “follow their noses” through your hypermedia representations. In the following example, we can find our way back to the account resource itself (useful if we did not fetch it initially but were given the representation as part of an orchestration), its recent orders, as well as individual orders.
1 < a c c o u n t i d = " 12345 " >
2 < l i n k r e l = " s e l f " h r e f = " h t t p : / / e x am pl e . com / a c c o u n t / i d / 1 2 3 4 5 " / >
3 b s l e t t e n < / name >
4 < s t a t u s > g o l d < / s t a t u s >
5 < r e c e n t O r d e r s h r e f = " h t t p : / / e x am pl e . com / o r d e r / a c c o u n t / i d / 1 2 3 4 5 / r e c e n t " >
6 < o r d e r i d = " 141234541234 " h r e f = " h t t p : / / e x am pl e . com / o r d e r / i d / 1 4 1 2 3 4 5 4 1 2 3 4 " >
7 < i t e m s > . . . < / i t e m s >
8 < / o r d e r >
9 < o r d e r i d = " 452354234534 " h r e f = " h t t p : / / e x am pl e . com / o r d e r / i d / 4 5 2 3 5 4 2 3 4 5 3 4 " >
10 < i t e m s > . . . < / i t e m s >"

"A slightly more verbose representation [of a collection]:
1 < a c c o u n t s h r e f = " h t t p : / / e x am pl e . com / a c c o u n t / s t a t u s / to p " >
2 < a c c o u n t i d = " 12345 " u s e r n am e = " j o j a l e h t o " s t a t u s = " a c t i v e "
3 h r e f = " h t t p : / / e x am pl e . com / a c c o u n t / i d / 1 2 3 4 5 " / >
4 < a c c o u n t i d = " 34246 " u s e r n am e = " bkemp " s t a t u s = " a c t i v e "
5 h r e f = " h t t p : / / e x am pl e . com / a c c o u n t / i d / 3 4 2 4 6 " / >
6 < a c c o u n t i d = " 77323 " u s e r n am e = " bl u u " s t a t u s = " d i s a b l e d "
7 h r e f = " h t t p : / / e x am pl e . com / a c c o u n t / i d / 7 7 3 2 3 " / >
8 < / a c c o u n t s >"

"The clients will not have to know how to paginate across arbitrary collections, they will simply discover links related to the collection with a rel type of next or previous. The server still drives URL layout, which is what we want in a hypermedia system."

This may not be as useful for external systems but seems more useful for internal systems where you can make your clients use the extra info.

The full book is available for $20.