How to organize URLs?

Suppose I have a web application with several modules that exist on both the server and the client side. Each module has some server URL paths to access/manipulate data for that module. For the sake of argument, suppose we have 'blogs' in our application.

For instance, the server URL path to get a blog might be /blogs/getBlog, and to save a blog开发者_高级运维 might be /blogs/saveBlog.

For the client-side, I can see two options:

1. Store the URLs in a single URL manager class. For instance, it would contain a property called getBlogUrl and saveBlogUrl, and more (similar) properties for the rest of the modules.
2. Store the URLs in each individual module. For instance, the Blog class might have the previously mentioned URLs as properties of itself.

When architecting your systems, which of these would you choose and why? Are there other options you might use to organize your URLs?

---

I personally tend to prefer URL schemes that follow a subject-verb pattern. For example:

/blog/new
/blog/{blog_id}
/blog/{blog_id}/newpost
/blog/{blog_id}/edit

Note that compound subjects are perfectly OK:

/blog/{blog_id}/post/{post_id}
/blog/{blog_id}/post/{post_id}/edit

Generally you don't want more than two ids though. If it gets more complex than that, you can create a URI-safe encoded protocol buffer that combines several ids together into an opaque compound id that can be deserialized into its component parts on the server side. So instead of:

/blog/{blog_id}/post/{post_id}/comment/{comment_id}

Use:

/comment/{merged_id}

You will probably want to stay consistent though. Try to avoid mixing-and-matching flat and hierarchical URI schemes. That tends to get confusing.

For APIs in particular, you generally want to prefix everything with /{api_name}/{api_version}/ because, as it turns out, making breaking changes to APIs doesn't endear you to the people using your APIs. Versioning allows any developers on your APIs to upgrade at their convenience and gives you a way to deprecate older formats and URIs schemes gracefully rather than all-at-once.

As far as clients keeping track of which URIs to call, one option would be to provide a discovery mechanism. This is what Google is doing for our next-generation API clients. The clients can auto-discover the URI structure from the discovery document, along with the list of required and optional parameters. This allows clients to be reused for multiple APIs and allows developers to work in either an RPC style or a REST style while decoupling much of the logic. There's certainly much more up-front work involved in this approach but it's totally worth it if your system is complex enough or if you have enough APIs that maintaining M API clients × N client languages becomes untenable.

---

I'd try different approach - identify modules by module identifier - just some unique string not based on location of the module. Let server modules register with the id and list of paths (relative URLs) to a registry module.

Registry module has the ability to translate paths to absolute URLs and has interface from which the client can read map of module identifier to list of module URLs (with some metadata if needed).

In client you can have singleton(?) registry module with getUrls(moduleId) method and all modules can read it from here. So in client module only the identifier is stored that is not supposed to change and also the registry module has simple and stable interface.