3 ms·

In theory, HATEOS is designed to resolve this problem. Quick 3 min draft example: https://gist.github.com/djames-bloom/2131d021a8f6d3d09c5a808626575a58 https:/

• emschwartz 4y ago
  Thanks for writing that up! I think it doesn’t quite answer what I’m after though. I’m thinking less about resource discoverability and more about authorization and fetching resources from the database. For example, if the URL doesn’t include the post ID and I need that to check if the user is authorized to post a comment, I’d first need to look up the comment thread to get the post.
  • clusterhacks 4y ago
    Interesting. I have used HATEOAS for a REST API. All requests were signed with a shared (between client and server) secret key. The shared secret keys were all associated with permissions to resource actions. In this case, the URLs never included anything in the route path that would have let you know that a user could execute an action. Instead, resource actions were limited to/owned by the shared key. A request to a route that had a different secret key owner would simply fail authorization unless the signature matched. The authorization headers included the API_ID that let the server side know which secret key to use to check the signature. This felt pretty good to me at the time - I basically looked at what AWS was doing with REST signatures and implemented a version of that for my purposes.