What are recommended programming patterns for passing identifiers/keys between server and client?

Question

If I need to keep track of a key or token that identifies a resource being displayed and modified in the browser, what are the some of the programming patterns used?

For example, if I display a list of movies and hookup ajax calls for users to checkout or review those movies, I'm assuming I would embed the identifier in the html which would then be passed back to the server.

Is it bad practice to use database keys? Is it bad practice to expose the identifiers in hrefs?

Answer 1

I don't consider a bad practice to expose a resource identifier to the clients. Doing so could overcomplex your system without any reason. If the database key is in fact your entity key, you can use it transparently.

The only pattern I can remember for displaying and editing data on the client side is DTO.

About the HREFs and your identifiers, a REST architecture would even recommend you to do so. It is a common practice ; )

Hope it helps you.

Answer 2

To start off, I do suggest using URIs to identify stuff. It's central to how the web works.

Exposing your database IDs to the client isn't too bad, but you should consider:

• Clients that know about database IDs and use them to do stuff are introducing a subtle form of coupling. The more clients expect of these IDs (e.g. that they're unique) the more coupling there is.
• Do the clients need to know that the items have database IDs at all? Perhaps it's OK to expose the ID buried inside a URI. Clients have no business disecting URIs to figure stuff out, so you're not strictly exposing it.
• If the clients need database IDs, could that be merely as a display identifier? You could then embed the database ID in the data going over the wire, but mark it up in such a way that it's understood that the ID should only be used to show users the identifier, in case they have a vested interest (because the ID is leaked elsewhere).

Removing the database ID from the URI suggest having another unique identifier which is not a primary key in some database.

Consider how e.g. Twitter's own twitter account has a list of the team:http://twitter.com/twitter/team The well designed URI exposes very little, so they could change their entire implementation without URIs being a problem. A single tweet on twitter has something which looks like a primary key http://twitter.com/meangrape/status/18622784109 but who's to know.