So I am creating a forum website (like reddit). On a thread, I want to have two different ways of requesting the thread's comments from the backend.

• One for if a user is not logged in.
• One for if a user is logged in.
  
  

With the request for when a user is not logged in
I want to just return the comments with an:

• upvoteCount value (for how many users upvoted the comment)
• no userUpvoted value (or userUpvoted = null)

With the request for when a user is logged in
I want to return:

• upvoteCount value
• userUpvoted value (so the frontend can display if the user upvoted the comment)

The endpoint will be something like this:

GET /thread/{threadID}/comments?startIndex={start index}&count={number of comments to return}

For the user that is logged in, I will send the authorization token in the header.
For the user that is not logged in, I will not send the authorization token in the header.

Is it possible to make sending the authorization header optional to an HTTP request like this?
Or should I just make two separate endpoints?

CodePudding user response：

Is it possible to make sending the authorization header optional to an HTTP request like this? Or should I just make two separate endpoints?

Yes, you can vary the representation (content) of a resource based on whether or not the authorization field is present in the request.

Is it a good idea? That's a harder question.

You already know how two separate resources works; there aren't going to be any significant surprises there.

We also have a standardized mechanism for indicating that multiple representations of a single resource are available.

But the Authorization field, specifically, is sort of a special case because of the role that field plays in access control; that has implications on how general purpose caches work, and therefore the Vary field that we use for indicating multiple representations has an exemption for the authorization field, etc....

If you submitted a single resource implementation like this for code review, I'd insist on a decision record as well, so that we have a permanent record of which trade offs we were considering (including, for instance, what's supposed to happen when Alice the Super Admin needs to verify the "anonymous" variation of the representation).