views:

17

answers:

1

Imagine a service where a User :has_many Events :through an Interest join model, and that there is an Interest#attending flag to indicate whether the user plans on being at the event.

If I want to return a list of events, but also include the value of the #attending flag for the current user, I could do this:

<interests>
  <interest>
    <attending>true</attending>
    <event>
       ...
    </event>
  </interest>
</interests>

But I'd also to return the value of the #attending flag for the authenticating when fetching just a single event. (To save a client having to make an extra HTTP request.) So, I'm tempted to return something more like this:

<events>
  <event>
    <attending>true</attending>
    ...
  </event>
</events>

Is there any reason not to take this approach?

A: 

Sounds like it depends on how the client uses the data. If they're writing back to your database then you'll have to translate their input to an acceptable format (no per-event attending status). But if it's just being displayed I don't see a problem with it. I've done this kind of de-normalization in certain situations; it always "feels" wrong, but I haven't had a problem with it as long as I document the behavior.

Alex Reisner
Good point. The example I gave doesn't show this, but in the actual app these are essentially read-only attributes and not directly modifiable by clients. Thanks.
Paul Horsfall