> BTW: Respect for your book, thanks for replying as I'd love to hear your views on the above.
<3. Trying to get more good stuff out there...
> Then the developer has to hope that the API implementor also knew about that spec and did the right thing.
This is why relations that aren't specified in your media type or in the IANA list are supposed to be URIs. If they're not, they're breaking the Web Linking spec.
> But the missing part of that story is "and to make a call to this particular end point you need to use one of these methods: HEAD, or GET".
There is no reason that text cannot be in every link relation. It's just not. When defining your own, absolutely add that in.
> And that permissions go beyond which resources can be touched, and into what actions you can perform on those resources.
This is certainly a good insight.
> Requiring a second HTTP request for everything to check these permissions seems a bit crazy in practise
<3. Trying to get more good stuff out there...
> Then the developer has to hope that the API implementor also knew about that spec and did the right thing.
This is why relations that aren't specified in your media type or in the IANA list are supposed to be URIs. If they're not, they're breaking the Web Linking spec.
> But the missing part of that story is "and to make a call to this particular end point you need to use one of these methods: HEAD, or GET".
There is no reason that text cannot be in every link relation. It's just not. When defining your own, absolutely add that in.
> And that permissions go beyond which resources can be touched, and into what actions you can perform on those resources.
This is certainly a good insight.
> Requiring a second HTTP request for everything to check these permissions seems a bit crazy in practise
I agree 100%.