Stan, Actually Arka is 100% correct and your reading of REST is very limited.
REST is more than just GET. It's basis is making use of standard HTTP calls of all varieties, including GET, POST, HEAD, PUT and DELETE to perform various actions on data resources.
Regarding linking: "REST accomplishes this by defining a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created."
or more simply "a URI identifies a concept rather than a document". So Arka's URI example of 'domain/products/productA' is spot on. URIs that link via the domino standard of 'db/view/unid' is way wrong because it's extremely likely to change over time. Whereas 'domain/products/productA' should be consistant and never change no matter where the actual resource lies on a server.
In this way URIs like this are actually FAR more usable and worth the trouble to create.
Stan, Actually Arka is 100% correct and your reading of REST is very limited.
REST is more than just GET. It's basis is making use of standard HTTP calls of all varieties, including GET, POST, HEAD, PUT and DELETE to perform various actions on data resources.
Regarding linking: "REST accomplishes this by defining a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created."
or more simply "a URI identifies a concept rather than a document". So Arka's URI example of 'domain/products/productA' is spot on. URIs that link via the domino standard of 'db/view/unid' is way wrong because it's extremely likely to change over time. Whereas 'domain/products/productA' should be consistant and never change no matter where the actual resource lies on a server.
In this way URIs like this are actually FAR more usable and worth the trouble to create.
If you want to learn about REST go here: {Link}