For pagination, you should be considering the techniques described in RFC 5005. Roughly, each page of results is a separate resource, which itself contains hyperlinks to the previous/next page of results. Then, as usual, the application can just follow the links to navigate from one application state to the next.
The actual spelling of the uri doesn't matter too much. You could treat the ranges as part of the query parameters, or as separate resources under a pages collection, or...
You'll want to give some thought to whether page 3 "now" has the same representation as page 3 at some other time. If not, you may want to have these resources redirect to another identifier that has a better caching lifetime.
Some apis will identify paging resources by putting the pagination data in the path; which isn't a great fit if you believe that the path should represent the position of a resource in a hierarchy. Query parameters are a much better fit.
As what you are doing is a safe query (no changes to server state), GET, rather than POST, is certainly the correct method to be considering.
Even if you need to allow the client to specify the query parameters (as opposed to defining the pagination links within the hypermedia), you should still be treating this as a simple GET. The heuristic to justify this choice is the behavior of a web browser, which packs parameters into the query string when a form with the get action is submitted. It works, it's stateless, the browser is still following a link contained within the application state.
If you aren't describing the application state with an html representation, then UriTemplates are a reasonable approach to representing the link. You could document the contraints on the parameters are part of the definition of the link relation.