In theory, HATEOS is designed to resolve this problem.
Quick 3 min draft example: https://gist.github.com/djames-bloom/2131d021a8f6d3d09c5a808...
Quick 3 min draft example: https://gist.github.com/djames-bloom/2131d021a8f6d3d09c5a808...
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.
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.