3 ms·

How is this premature optimization? Since it's equivalent to the alternative, it should be known that this way has an advantage.

• stickfigure 4y ago
  Adding a ton of structural noise is not "equivalent". This pattern will be repeated throughout your hierarchy, and your clients will have to deal with this: GET /assets/123 { "Asset": { "owner": { "Person": { "name": "Bob", "contact": { "Address": { "street1": "blah", ... } } } } } } On the other hand, the traditional approach: GET /assets/123 { "owner": { "type": "Person", "name": "Bob", "contact": { "type": "Address", "street1": "blah", ... } } } } This is much more sane to navigate. And when you end up making some previously-static node polymorphic (as happens), the structure does not change.
  • FeepingCreature 4y ago
    I think making a previously-static node polymorphic in a way that doesn't drop any required field is actually quite rare. But also, I just think the first one is better.
    • stickfigure 4y ago
      It's much easier to migrate adding/dropping fields than to make structural changes. Adding/dropping fields is the easiest form of migration. I honestly have a hard time believing that you prefer: asset.Asset.owner.Person.contact.Address.street1 to: asset.owner.contact.street1 If so, I think you should really announce this first and foremost in your article so that everyone can take a proper measure of your sanity :-)
      • FeepingCreature 4y ago
        I mean, I don't actually believe you that all those levels are polymorphic. :-) IME, we have one, at most two polymorphic fields per message. And for an example chosen deliberately to be annoying, I still like the deeper tree better- at least it advertises that something unusual is going on.