1

I have an endpoint /api/properties which returns a dynamic list of properties, e.g.

{
  userId: 1,
  groupId: 2,
  ...
}

The difficult part is that most of the properties are integers (ids) and I would like to display these properties in a human readable format, e.g. instead of user id and group id I would like to display like this:

User: <userFullName (userId)>
Group: <groupName (groupId)>

So I was thinking of 2 options:

Option 1:

{
  userId: 1,
  groupId: 2,
  ...
  config: {
    userId: {
      label: "User"
      fullName: "fullName"
    },
    groupId: {
      label: "Group"
      name: "name"
    },
    ...
  }
}

Option 2:

[
  {
    name: "userId",
    value: 1,
    label: "User",
    userFullName: "fullName"
  },
  {
    name: "groupId",
    value: 2,
    label: "Group"
    groupName: "name"
  },
  ...
]

What data structure will be the best for this situation?

2
  • Why don't you return the strings formatted from the server? Do you need all the fine-grained detail of "label", "groupName", "name"? Why so verbose?
    – Laiv
    Nov 1 '19 at 19:07
  • I was thinking about this option too Nov 19 '19 at 10:09
1

If I understand well your intent:

  • you would like your backend to tell about the properties that its API provides
  • you would like your frontend to tell the user what it’s about, without having itself any knowledge about the data model
  • otherwise said, instead of userid and group id, your backend might as well offer fruitid and vegetableid instead.

Basically this approach is a lot like a data dictionary that highly customizable systems offer.

Your option 2 has the advantage of providing in one step the full definition of a property. I believe, this is the simplest to use for your client.

Your option 1 has the advantage separating language specific elements from the data definition itself. You need then to combine several items before being able to use them. You could also imagine to extend your approach for making a multilingual frontend (language id would be needed then).

Finally, you could imagine an option 3 that combines both benefits: you would provide all the core information (e.g. property type, minimum maximum value/length, etc) in a format similar to option 2. But you would provide language specific info separately, as in option 1. This would of course be more complex than option 2, but it is very powerful.

There’s little context that could allow to recommend one of these options on an objective basis. But you have now the pros and the cons and should be able to decide if the extra complexity is worth the extra benefits.

0

Neither.

Request the user and group objects or lists of them seperately so that you can reuse them.

1
  • I was thinking to obtain all data using 1 request Oct 31 '19 at 15:00
0

Depending on the semantics of your interface, i'd suggest a third option. Your original idea suggests that there can be only one user and one group field. Your Option 2 on the other hand allows for this:

[
  { name: "userId", value: 1, ...},
  { name: "userId", value: 2, ...},
  ...
]

which you may or may not want, since you have no method of disallowing this. But what about:

{
  user: { uid: 1, label: "User", userFullName: "fullName" },
  group: { gid: 2, label: "Group", groupName: "name" }
}

this keeps all user data together in one node, allows for clients to parse/write only user.uid and group.gid if they wish, and is extensible enough that richer clients can make use of the extra data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.