The rationale is: /me defaults to published articles, drafts are an explicit permission with the OAuth2 authentication we were testing, hence the default.
If you want me/all and me/unpublished with OAuth2 you need to ask explicit permission to the user. me/published probably wasn't necessary in hindsight, since it's exactly like /me without further qualifiers
Feels slightly awkward, still : ) I always expect (perhaps just me) the last sub-resource to tell me what it's going to bring back, so in this case /articles/me looks like it's going to bring back information about myself.
IMHO it could be more REST-full and more elegant if it was:
/me # Brings information back about authenticated user.
/me/articles # To bring back information about my own articles.
And then it could have a query parameter with an enum value to bring back reports of certain status, e.g. status = [draft,published,unpublished]
And then have it as follows:
/me/articles # can default to all, or published
/me/articles?status=published
/me/articles?status=draft
/me/articles?status=unpublished
or accept multiple statuses:
/me/articles?status=draft&status=published
At least that's how I would model it. Other than that - it's looking good.
Curious.
How are
/articles/meand/articles/me/publisheddifferent? They seem to have exactly same descriptions : /Also
/articles/me/allseems awkward, shouldn't this have been/articles/me? :)Yeah, that was weird :D
The rationale is:
/medefaults to published articles, drafts are an explicit permission with the OAuth2 authentication we were testing, hence the default.If you want
me/allandme/unpublishedwith OAuth2 you need to ask explicit permission to the user.me/publishedprobably wasn't necessary in hindsight, since it's exactly like/mewithout further qualifiersFeels slightly awkward, still : ) I always expect (perhaps just me) the last sub-resource to tell me what it's going to bring back, so in this case
/articles/melooks like it's going to bring back information about myself.IMHO it could be more REST-full and more elegant if it was:
And then it could have a query parameter with an enum value to bring back reports of certain status, e.g.
status = [draft,published,unpublished]And then have it as follows:
or accept multiple statuses:
At least that's how I would model it. Other than that - it's looking good.
Great job!
This is the conversation we should definitely have when we go to break ground on v1.
v0 is definitely gonna be a mishmash of whatever it takes to offer a technically sound API of any kind 😄
That is totally fine, it's better to start with anything that works instead of aiming for perfection :)
Yeah, the next version will get closer to that, after all mistakes are a way to learn!