2

Currently I experiment with the GitHub API, and I noticed the following: if you request an issue, it has both an assignee and a set of assignees - with the same properties as the user above. This feature was introduced a year ago, as it seems.

While I see the reason for having assignees, I don't understand why to have both properties, especially if, in the case of having assignees set, the first one will always be the assignee. Why isn't the set of assignees enough to store the information? One thing I can imagine is keeping assignee for legacy reasons, but what other explanation can be?

Here is a good example, right on the official GitHub page. As you can see, assignee is octocat, and after calling the POST /repos/:owner/:repo/issues/:number/assignees, the assignees will be octocat and the two new users.

Akabelle
  • 398
  • 4
  • 13
  • 1
    Somewhat related Assignee vs Reviewer. https://stackoverflow.com/a/41348853/342794 – lal Dec 01 '17 at 20:06

1 Answers1

1

I haven't seen any official rationale from Github, but I think it's safe to say that it has to do with maintaining API compatibility.

They couldn't just change the assignee field from being a single user object to being a list of user objects since that would break existing API clients that assume it is always a single object.

They also didn't want to bump the API version to V4 for a small change like that.

So the solution is to add a new assignees field, existing API clients still works (although you don't get all the assignees) and new code that is being developed can use the new assignees field.

johlo
  • 5,422
  • 1
  • 18
  • 32