fix: top-level links based on request_path if present

[grzuy]

Closes #466

Thoughts on defaulting to Conn.request_path to fix this?

Another option would be to allow the View/Serializer to receive this per-operation path as an argument during a request/response cycle somehow, right?

[mattpolzin]

I think the tricky thing here is that the existing strategy and the one you are proposing both have strengths and weaknesses.

As you note, the existing strategy fails to automatically apply to two distinct routes both surfacing the same primary resource using the same view.

On the other hand, your new strategy fails to automatically handle reverse-proxying that would make the request path as seen in the Elixir service not accurate to the outside world.

Each weakness is the other strategy's strength, too. The existing strategy works well in reverse proxied settings because it produces a canonical external URL. Your new strategy works well in multiple route situations because it does not rely on the assumption that a resource is served from one canonical route.

In the end, given the fact that all of this is nearly infinitely customizable by the library (you can write your own url_for and you can write your own url_for_pagination and you can write your own Pagination module), I am not sure how to pick the "best" default behavior other than to leave it alone since that is the option that is non-breaking.