Two things:

1) Yes, you should only use info supplied by the API. This should mean that the API is helping to ensure the client never sends the user down a UX dead-end, and also that the client does not break when the API changes.

But...

2) I don't like the thought of collections having a resource identifier for a page. As items are deleted from the collection, the resource identifiers now represent a modified resource and break caching (delete item 3 of a 5 item per page collection, and all resources in the collection - logical pages - have been modified implicitly).

I much prefer using query string for this, as it is a query on a collection.

But... the API should still be the thing that generates/builds these URLs, the client should never do this work. The client must use the provided first|prev|self|next|last URLs, otherwise the client may break in the future.

An example of how I prefer pagination:

    "collectionName": {
      "total": 861,
      "limit": 10,
      "offset": 100,
      "pages": 87,
      "links": [
        {"rel": "first", "href": "/api/things?limit=10"},
        {"rel": "prev", "href": "/api/things?limit=10&offset=90"},
        {"rel": "self", "href": "/api/things?limit=10&offset=100"},
        {"rel": "next", "href": "/api/things?limit=10&offset=110"},
        {"rel": "last", "href": "/api/things?limit=10&offset=860"},
      ],
      "items": [
        ...
      ]
    }

Where 'limit' and 'offset' are provided by the query string (but default to 25 and 0 respectively) and the API takes care of generating valid links (like not including 'prev' if you are on the first page').

This way the client does what it should, just use the links provided.

And whilst I'm here... one of the things I dislike about link relations is how they presently fail to mention the method you should use (let alone content-types acceptable by that end-point).

In the example above every link is a GET, in the example on this page http://restcookbook.com/Basics/hateoas/ they're probably POST. In the link relation assignments http://www.iana.org/assignments/link-relations/link-relation... 'edit' is probably a PUT. There's an 'edit', but not a 'delete', so it's not as if just sending more than one 'rel' might describe the method.

Today the audience of an API is a developer, so it's fine to just point them at the documentation. But tomorrow it may well be a computer.