1

conclusion

a very short dialog with systempunotout showed me that I could look at this another way that makes a nested structure make perfect sense.

the q remains for reference.

This should be flattened. there is no chance that there will be an array of badge counts and the structure represents a 1 to 1.

It unnecessarily complicates deserialization and/or necessitates an additional class.

it should be flattened.

   "user_mentioned_url": "/users/22656/mentioned",
   "user_comments_url": "/users/22656/comments",
   "user_reputation_url": "/users/22656/reputation",
   "badge_counts": {
    "gold": 37,
    "silver": 679,
    "bronze": 1277
   }
  },

responses

to koning - not sure how you come to that conclusion...

245 bytes:

   "user_mentioned_url": "/users/22656/mentioned",
   "user_comments_url": "/users/22656/comments",
   "user_reputation_url": "/users/22656/reputation",
   "badge_counts": {
    "gold": 37,
    "silver": 679,
    "bronze": 1277
   }
  },

236 bytes:

   "user_mentioned_url": "/users/22656/mentioned",
   "user_comments_url": "/users/22656/comments",
   "user_reputation_url": "/users/22656/reputation",
   "gold_badges": 37,
   "silver_badges": 679,
   "bronze_badges": 1277,
  },

the difference is greater if the results are not pretty printed.

What is the benefit of nesting this information? I am having a hard time seeing it. It is artificial and adds complexity.

Improve this question
11
  • It's not a bug. It's status-bydesign.
    – user451
    Commented Jun 20, 2010 at 12:03
  • @code i'm not getting your point here, could you elaborate a little bit? I see badges well wrapped on badge_counts key, why do you think they need to ble flattened?
    – systempuntoout
    Commented Jun 20, 2010 at 12:12
  • I don't see any reason to flatten this.
    – Dennis Williamson
    Commented Jun 20, 2010 at 14:13
  • Not trying to be mean, but can I downvote this twice?
    – Matt S.
    Commented Jun 20, 2010 at 16:52
  • 1
    @matt - no, but you can explain why you would want to.
    – Sky Sanders
    Commented Jun 20, 2010 at 16:56
  • 1
    because your question doesn't make sense. If I want to get badge data, I would want it to be in a spot where I can easily find it in the documentation. Maybe if there was one or two types of badges then your question would be valid, but with three it makes more sense to display it as a nested structure. That way, when I'm trying to find all badge data, I know that it's all contained within badge_counts and that that'll be the only place badge data is in.
    – Matt S.
    Commented Jun 20, 2010 at 17:42
  • @matt - so, you arbitrarily place the 'candidate for flattening member count' at 2, indicating that you believe that there could be a case yet state that my suggestion makes no sense. you might want to examine the fallacies represented by your comments. peace.
    – Sky Sanders
    Commented Jun 20, 2010 at 19:28
  • @code a stellar or wooden badge type could be added in the future, what do you know?
    – systempuntoout
    Commented Jun 20, 2010 at 19:45
  • @system - then a new field will need to be added to the api somewhere. what's the difference. what do i know? not much and less every day.
    – Sky Sanders
    Commented Jun 20, 2010 at 19:47
  • 1
    @code yes but using 'badge_counts' you will have your badges collection ready to use without changing a comma in your code. Adding a new field somewhere is not that clean.
    – systempuntoout
    Commented Jun 20, 2010 at 20:39
  • 1
    @system - ok, i am starting to see where you are going with this and you are right.
    – Sky Sanders
    Commented Jun 20, 2010 at 20:44

1 Answer 1

Reset to default
1

This is clean, and uses less bandwith. Period.

Improve this answer
10
  • This. I also have trouble seeing how a fixed-size nested structure is in any way difficult to deserialize.
    – Kevin Montrose
    Commented Jun 20, 2010 at 15:49
  • Koning - are you agreeing with me or disagreeing with me? I am not sure, but am responding as if you are disagreeing. let me know.
    – Sky Sanders
    Commented Jun 20, 2010 at 17:03
  • @kevin - i see no mention of 'difficulty'. i am reacting to unnecessary complexity. there is a difference.
    – Sky Sanders
    Commented Jun 20, 2010 at 20:07
  • @code poet - s/difficult/complex then.
    – Kevin Montrose
    Commented Jun 20, 2010 at 20:28
  • 1
    @kevin - complexity is not a subjective term. if i did not have an idea of your ability i would respond 'if you don't see how either requiring out of band flattening or the introduction of a nested class and the necessity of then flattening that for introduction to a persistent store such as a db or adding a m:n table structure to store the information adds to complexity then i suggest golf' but I do have an idea of your ability so i will suggest examining this, and other, suggestions from a neutral perspective, refrain from making determinations of the correct manner in
    – Sky Sanders
    Commented Jun 20, 2010 at 20:38
  • 1
    @kevin - which to consume the api and simply entertain the possiblity that the suggestions are a result of the actual experiences of the users of the api and as such have a degree of validity built in that should be paid at least a token degree of respect.
    – Sky Sanders
    Commented Jun 20, 2010 at 20:39
  • 1
    @kevin - categorical dismissal of the concerns of your users is not the path of least resistance and optimal outcome. refer to the dialog systempuntoout and I have in the comments of the Q for an example.
    – Sky Sanders
    Commented Jun 20, 2010 at 20:45
  • @code poet - If we were exporting data explicitly for import to a database, I'd agree with you. But we're not. We're pushing out objects, and object<->relational mapping is hard; that's the root of your issue. Completely flat objects being something of a pathology in OO design, nesting is intended (in general, and in this particular case) to keep similar/related data in the same conceptual unit. Thus, all the badge counts are held together.
    – Kevin Montrose
    Commented Jun 20, 2010 at 21:23
  • 1
    @code poet - Also, sorry if I come across as rude. That is not my intent. I strive for brevity, because time spent composing responses is time not spent fixing issues, or implementing new features.
    – Kevin Montrose
    Commented Jun 20, 2010 at 21:26
  • 1
    @kevin - thanks for the acknowledgement r.e. tone of response. In this case you are all correct and I have seen the light. And my examples were examples only. I am not mapping to db, funnily enough. I am implementing a persistence layer in an x-plat OODB, Perst, that implements a compact, high performance full-text indexable database that will run in silverlight,.net and mono and backing it with soapi.
    – Sky Sanders
    Commented Jun 20, 2010 at 22:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .