Using a hash as part of id - http

Question

I am building a REST service as part of my rails app, and I'm wondering if it is bad to expose the ID with a unique hash or timestamp appended to it for each resource.
What I want to achieve is that the client will then know if it has the same resource as the server, and if not, then update it.
An example:
the event resource would look like this in JSON
event: {
id: 123-kjkjlhhkh,
name: event-name,
date: somedate,
users: [456-sadasdasdas, 242-asfat4fdhs]
}
the client would have an event table and a user table, that would look something like this:
Events id | id-hash | name | date
--------------------------------------------------
123 | kjkjlhhkh | event-name | somedate
Users id | id-hash | username
--------------------------------------------
456 | sadasdasdas | oldusername
242 | kkskksksk | someusername
This means that we see on the client side that the user 242 has a new hash appended to the id, which means that the user resource has changed on the server and we can go grab it.
So the question is, is it better(more RESTful) to send the whole user resource (for all the users) together with the event, or to just send the ID:s with appended hashes and get the whole resources from the server in a separate call if they are different than the local ones?

Answer 1

I wouldn't mangle the IDs.
Technically, resources are identified by their URL. So if you have a different URL, you have a different resource. Also, having arbitrary IDs attached makes discovering and using your URLS really hard.
What you should do instead is to use ETags instead. These are typically used for caching of resources. An etag should identify a resource version so that a client use a request header like this:
If-None-Match: "686897696a7c876b7e"
to only get the newest resource if the server version doesn't match the provided ETag. In your case, you could just use your ID hash as an Etag. That way, you use standard HTTP mechanisms and don't have to reinvent the wheel.