If this Facebook Graph API is restful

Question

Facebook has an API to get your photos:

GET graph.facebook.com
  /me/photos

/me/ is a shortcut for the Id of the person logged in. Is that introducing state into the session and therefore is it restful?

Would it not be more restful to do:

/user/1234/photos

and then have some security layer to make sure only users with the appropriate token can access that URL?

https://developers.facebook.com/docs/graph-api/using-graph-api

Noticing some other places use this pattern. For example:

Stripe do this for GET all coupons:

GET https://api.stripe.com/v1/coupons

Paypal do this for all payments:

GET /v1/payments/payment

https://developer.paypal.com/docs/api/payments/

Answer 1

GraphQL is not restful, I tried to sum this up here.

The /me does not necessarily introduce state, because the id for me could be in the headers, so the serverside can still be stateless.

Is that introducing state into the session and therefore is it restful?

In fact statelessness is a constraint for rest, so you would have to rephrase your question to "... therefore is it not restful"

But REST relies heavily on URIs, so this shortcut circumvents being transparent in the URI, what is not the best idea according to restful principles.

Answer 2

REST IS a concept/approach/way to provide interoperability between computer systems.

REST IS NOT a standard, approved by a committee/organization in terms of strict regulations.

While there are architectural constraints, recommendations, unwritten rules, common solutions, you can't truly affirm this is rest or this is not rest. Everyone design its service as he thinks it's better.

Graph API is not exactly REST, they are a bit just different things/meanings.

Related to FB /me they said:

The /me node is a special endpoint that translates to the user_id of the person (or the page_id of the Facebook Page) whose access token is currently being used to make the API calls.

As this URI depends on authenticated user, what's the problem with it?

Related to PayPal, I think You prefer /v1/payments/payment instead of /v1/payments/35/payment, but the same app deployed to another customer will be /v1/payments/69/payment or a logout like /v1/user/35/logout.

It's all about convenience.