When implementing RESTful services should lookup v

问题:

I am creating RESTful services for several database entities based on a modified version of the BISDM. Some of these entities have associated lookup tables, such as depicted below:

The lookup tables are associated with one and only one table. Additionally, the lookup tables will be used by the client application to populate dropdown lists, treeviews, and comboboxes for the editable fields of their associated entity table.

Should lookup values / table get their own URI or should they "share" one with the parent to which they are associated? What are the pros / cons of each?

Option 1:
   /Entities/Spaces/SpaceCategories/
Option 2:
   /Lookups/SpaceCategories/

回答1:

In a RESTful system, the way your URLs are constructed is not nearly as important as the resources you identify and the names you give them.

From what you've shown, it looks like you have three resources:

• Space
• SpaceCategory
• Lookup

The URIs you give to these resources are largely a matter of taste. For example, nothing in REST prevents you from defining a URI system in which every resource, regardless of its type, is assigned a hash code and accessed through:

http://example.com/{hash}

Some frameworks, such as Rails, make it convenient to create nested resource URI heirarchies using the name of the resource in the URI. But this is just a convention your application can follow or not.

REST defines a number of constraints, one of the most difficult to grok is that an application be hypertext-driven. One of the advantages of this constraint is that it promotes loose coupling between your app and its clients.

The idea is that when a client requests a resource through a URI, part of the contract is that the client can only choose another URI based on the links provided in the resource representation. This is not unlike the way you use a browser to follow links in a web page.

This contrasts with a RPC-style approach where URI templates are published and become hardwired into client code.

If at some point in the future you decide nested URIs work better than flat ones, you can change your URI scheme and it won't break any client code. You can even move resources to a completely different domain, or change protocols from HTTP to HTTPS, or FTP. Your URI templates haven't been published and so no client code should have been written against them.

Instead, your application simply begins serving the new links, and the client starts following those.

I found all of this mind-numbingly abstract when I was initially exposed to it (and am still feeling my way). There aren't many examples that illustrate the concept, but for one, check out the Sun Cloud API.

回答2:

URIs might as well be unreadable, urlsafe, encoded binary. It doesn't matter how you construct them. This has nothing to do with REST.

回答3:

While I agree with Wahnfrieden that the construction of URLs has nothing to do with REST (as long as they uniquely identify a resource), one of the unspoken goals of RESTful interfaces seems to be human comprehensibility. So it makes sense to have URLs that at least give a sense of how the data should be accessed.

So, how is your data accessed? Are the lookup tables shared between multiple "parent" tables? That would indicate your second approach. Are they specific to a single parent? That would indicate the first.

But then there's the question of why you're exposing the lookup tables in the first place. If it's for client-side validation, then the second approach makes more sense, because it partitions the "helper" data from the "real" data (although I'd probably give it a URL that indicates the relationship to the parent).

On the other hand, if you're expecting clients to use the lookup tables to do lookups themselves ... don't. Yeah, it's nice to keep data normalized, but (1) it's more usable if you return data with the lookups already filled in, and (2) if you don't, you're going to multiply the traffic on your server.