I am looking for best practice principle here. As part of my REST Api, I am returning some basic info for a user. Lets say the user can be an "owner" of a company, in which case they have full access to every resource of the company. Or they could have been given delegated access to certain parts of the company. Now I have these two choices of json to return

if user is an owner ...

     companyId : "123",
     companyName: "Acme",
     isOwner: true,
     delegatedAuthority : null 

if user has delegated access to certain resources of the company ...

     companyId : "123",
     companyName: "Acme",
     isOwner: false,
     delegatedAuthority : 
            // An object that provides all the details about the delegation.

Obviously, from an implementation perspecitive, I would be doing something as simple as setting isOwner = delegatedAuthority == null behind the scenes.

But should I even returning the flag? From an exploratory or descriptive perspective, it seems like a nice thing to return. Could be helpful for someone building a consumer who might not be familiar with the API or the domain. But for someone familiar with the API/domain, it seems like I might be violating DRY and returning redundant information. Would they now feel compelled to write error checking code to make sure I don't lie to them and return both the isOwner = true and delegatedAuthority != null

What are the principles you would consider and weigh?

  • I don't think REST pertains much here, as this question doesn't relate to URIs, links, status codes, verbs, or headers – Jack Feb 23 '17 at 2:07
  • 1
    @Jack I am talking about how best to "REpresent" a certain "State" in my application. Which is the fundamental core concept of REST. URIs, links, status codes, verbs, headers are all related to a specific implementation (HTTP) of REST. – Chaitanya Feb 23 '17 at 2:27

Is It always obvious? What if what determines isOwner changes behind the scenes?

There will be a ton of client code that will break, if the association between the two fields is gone.

Thinking about an interface, I would keep isOwner. If the underlying relation changes, your clients wont break.

  • Very unlikely that the association will change as far as I can see. Basically, companies have owners which is the default and standard. Occasionally a company owner might delegate a bit of functionality to someone else. An accountant to pay some bills for example. Doesn't make sense for someone to be both an owner of a company and it's delegate too. – Chaitanya Feb 23 '17 at 3:48
  • 2
    @Chaitanya: Your view is a bit too simplistic for publicly owned companies. There I could be a part-owner (because I own stock in the company) and only have some delegated authority (because I am an employee with some limited authority). – Bart van Ingen Schenau Feb 23 '17 at 11:35
  • Regardless of you think its true and standard, the right move in my opinion is to keep the calculated value, in other cases as well. This is more future proof. As we know requirements changes 😀 – George Silva Feb 23 '17 at 16:40

It is wise to build your business logic in one place. In your case business logic is: if that data structure delegatedAuthority is missing, the person is owner.

You should encapsulate the logic in one method. It is up to you if you do it on server side or client side. If it is implemented on server side, return the boolean in REST call. You can also only return data structure, but then I suggest you implement the logic in client side. Eg you are not checking everywhere if delegatedAuthority != null but you have one piece of code that consumes the REST endpoint and provides isOwner() functionality for you.

On the other hand - you could also rebuild your API so that instead of isOwner you are returning role that may also contain other roles that are currently stored in delegatedAuthority. Eg return the same data structure for owners and other people. But again - this is not only a question of single endpoint, but rather a decision of where to build your business logic in general.

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.