> If you have your routes designated in a central area , this shouldn't be a problem anyways right?

It's not a problem for the server (and even then, it might be: what if the root handler simply sends to further sub-handlers after just chopping off part of the URL or query arguments? There isn't necessarily a central URL authority on the servier either), but generally is one for the client: in a truly RESTful system, the client knows one URL and one only (the service's root).

It also knows all the media types the service can return (which is why meaningful content-types, as those returned by Github, are great).

From this, it can traverse the service to the place it needs, and it may cache URLs along the way (for more efficient traversals later on) but those URLs may die altogether and require a re-traversal.

This scenario is built into the architectural style.

> In fact, you need to designate this someplace anyways, whether it's on your server (in the database or in some code), or on the client-side code.

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.

>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?

> 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.

> 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.

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.

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.

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.

If you use URLs instead of IDs, that central area moves from the client to the server.

Having worked with both types, the URL type REST is far far easier to write clients for.