The "me" link breaks the EntryPoint when user resource is internal

Great catch!

Just one silly CS violation that caused it to not be green. Fixing, RTBC'ing, committing when it comes back green.

Actually, leaving RTBC to let @gabsullice also +1 this approach.

I'm fine with a try/catch vs. detecting if the route is not defined. However, the promise of the me link is mostly that it communicates the consumer's authentication state, i.e. the presence of the me links tells the client that it is authenticated vs anonymous.

I'd rather not remove this feature simply because the user is internal. I wonder if there's something else we could do...

Here's an alternative approach that won't break the signaling effect of me, the link will just resolve to a 404.

Easy fix.

I agree that it's weird to point to a missing URL. I tried to think of something else, but nothing seemed cleaner (like a null href or pointing to a different URL). This is the least disruptive change I could think of.

The me link has three functions, to point you to the resource that represents the current user, to indicate that the client is authenticated and to communicate the current user's UUID (so that you can filter to get a list "My Articles", for example). If we go with #4, we're killing all three of those functions. If we go with #7, we're only killing 1 of those functions.

I find that #7 will lead to confusion. As an API user I don't want to get links that don't exist. I don't think that people will disable the user resource type and be furious because the "me" link is missing.

I'd ask, isn't it more confusing that the me link disappears because you disabled the user resource type than it is for it to be 404?

If you follow the link and get a 404, I think it's a smaller mental leap to think "oh, it's 404 because I disabled the resource type" than it is when you're looking at the me link to see if you're authenticated and it's gone because you disabled a resource type.

I think most developers in that scenario would start looking at their headers and cookies and such first, only to slap their head when they finally realize it's just because they made the user resource type internal.

In essence, I don't think that people will disable the user resource type and be furious because the "me" link is missing404.

Who's glad he didn't just go ahead and commit this? ✋

😃

I think it's a great point that this removes the ability to get the current client's User UUID, which is essential for certain operations (filtering to "my content"). Isn't that a concern of yours, @e0ipso?
I suspect you think that if a particular site chooses to disable User, that its data model and hence clients don't care about users/ownership at all?

@e0ipso, hmm, it seems we need to find a way that this won't throw an exception and end up in head-scratching.

What if we add a meta.id member to the me link object. So when the route is present we have:

{
  "links": {
    "me: {
      "href": "/jsonapi/user/user/{uuid}",
      "meta": {
        "id": "{uuid}"
      }
    }
  }
}

but when it's not, we have:

{
  "links": {
    "me: {
      "meta": {
        "id": "{uuid}"
      }
    }
  }
}

That's technically okay by the spec (but I really think only because of an oversight): "[A link object] can contain the following members [href</code and <code>meta"

Alternatively, we could change the me structure a little bit. Right now, it's a link under meta, but it could be a resource object under meta instead:

{
  "meta": {
    "me": {
      "type": "user--user",
      "id": "{uuid}",
      "links: {
        "self": {
          "href": "/jsonapi/user/user/{uuid}"
        }
      }
    }
  }
}

Interesting proposals. I could live with either. I defer to @e0ipso to pick a direction. Or perhaps he has a different proposal still.

I would like to not have a link to a 404

+1

This is blocking the adoption of 2.x by Contenta CMS.

Interesting! Is Contenta CMS disabling the user--user resource type by default?

But even if it didn't, since we ship with JSON:API Extras enabled it'd be a blocker anyways.

How does this issue and the "me" link in general relate to JSON:API Extras? It feels like I'm missing something here! 🤔

Ahhhh, now I get what you meant! Thanks for clarifying :)

@e0ipso So, which in the proposals of #14 do you prefer?

#26: on it!

#3019389 has a green patch on 8.6 and 8.7, but a red one on 8.5, due to another commit having broken JSON:API in 8.5. Blocked on that.

In the mean time, this could already be reviewed by @gabesullice, who had strong opinions about this than I did I think.

#24 LGTM. Thanks for pushing forward on this despite the frustration of a seemingly minor thing growing much bigger 🤗

RTBC, once all tests pass (this should happen when HEAD is unbroken).

Yay!

Blockers have landed. Retesting.