4 ms·

>If URLs are designated anywhere in the client-side code (outside of the root service URL and a URL cache, which is accumulated knowledge rather than built-in),

by jwingy 15y ago

>If URLs are designated anywhere in the client-side code (outside of the root service URL and a URL cache, which is accumulated knowledge rather than built-in), it's not a RESTful service, it's RPC-over-HTTP. But certainly the client needs to know something about the base resources such as product or user? How else will the client know where it can fetch the appropriate resource?

pornel 15y ago
It will know by discovering URLs on each step — the same way you browse a website without knowing all of its URL structure in advance. Each HTML response has links and forms that show how to get the next thing.
- jwingy 15y ago
  Ahh, I think I understand where I'm misinterpreting things. I've been building a purely javascript based website so I've been thinking from that perspective instead of the more traditional page by page approach where this makes more sense when described in these terms. It's definitely still possible to build a RESTful service, but I think if you're primarily building in js, you tend to have more routes that return resources without URLs to other resources than ones that do, especially when you're just starting out and don't have a comprehensive list of resources you want to represent and the accepted mime-types you'd like to be able to return.
bct 15y ago
> But certainly the client needs to know something about the base resources Yes, it needs to understand how they're represented, what types of links they might have to other resources, etc. A good example is the Atom Publishing Protocol (RFC 5023). It's specified entirely in terms of representation formats, resource types, and the actions that can be performed upon those resources.
gte910h 15y ago
Read all the rest tutorials and papers. It only takes a couple hours, it will get it across and it works so much better for client writers.
masklinn 15y ago
> But certainly the client needs to know something about the base resources such as product or user? Of course, that's the "media types" part, it's the complete description/knowledge of a type of resource returned by the service. The media type returned by the service's root is the gateway to the rest of the service. That's the part which is generally missed in RPC-over-URL services claiming to be restful: they exhaustively describe the shape of all the URLs in the system, and then just quickly pass over the media types (the resources at these URLs). That's doing it literally the wrong way around, a RESTful service documentation should be absolutely exhaustive in its description of the media types, the only "hardcoded" URL of interest to the client is the service root and it only takes a line to specify.

by jwingy 15y ago

pornel 15y ago

It will know by discovering URLs on each step — the same way you browse a website without knowing all of its URL structure in advance. Each HTML response has links and forms that show how to get the next thing.

jwingy 15y ago
Ahh, I think I understand where I'm misinterpreting things. I've been building a purely javascript based website so I've been thinking from that perspective instead of the more traditional page by page approach where this makes more sense when described in these terms. It's definitely still possible to build a RESTful service, but I think if you're primarily building in js, you tend to have more routes that return resources without URLs to other resources than ones that do, especially when you're just starting out and don't have a comprehensive list of resources you want to represent and the accepted mime-types you'd like to be able to return.

bct 15y ago

> But certainly the client needs to know something about the base resources Yes, it needs to understand how they're represented, what types of links they might have to other resources, etc. A good example is the Atom Publishing Protocol (RFC 5023). It's specified entirely in terms of representation formats, resource types, and the actions that can be performed upon those resources.

gte910h 15y ago

Read all the rest tutorials and papers. It only takes a couple hours, it will get it across and it works so much better for client writers.

masklinn 15y ago

> But certainly the client needs to know something about the base resources such as product or user? Of course, that's the "media types" part, it's the complete description/knowledge of a type of resource returned by the service. The media type returned by the service's root is the gateway to the rest of the service. That's the part which is generally missed in RPC-over-URL services claiming to be restful: they exhaustively describe the shape of all the URLs in the system, and then just quickly pass over the media types (the resources at these URLs). That's doing it literally the wrong way around, a RESTful service documentation should be absolutely exhaustive in its description of the media types, the only "hardcoded" URL of interest to the client is the service root and it only takes a line to specify.