A server MAY add additional state tracking parameters to the links, as shown in the example above, though the server need not use a stateful paging method as shown in this example - it is at the discretion of the server how to best ensure that the continuation retains integrity in the context of ongoing changes to the resources
Currently HAPI FHIR forces to use stateful pagination and hides initial search parameters in next/prev links, so there is no way to get them except saving on the server side. That complicates implementation for most common cases, when each page request can be retrieved from the database with no need for full resultset cache or continuation control. To retrieve the search metadata by request id in multi-node environment, we need to introduce additional infrastructure (e.g. cache with TTL support) or use sticky sessions, while parameters can be available in the user request.
I think the problem is more or less the whole search implementation. I've been working on some initial proof-of-concept of the stateless paging on the db level in #2059.
Describe the issue
FHIR pagination documentation states, that server may or may not use stateful pagination:
Currently HAPI FHIR forces to use stateful pagination and hides initial search parameters in next/prev links, so there is no way to get them except saving on the server side. That complicates implementation for most common cases, when each page request can be retrieved from the database with no need for full resultset cache or continuation control. To retrieve the search metadata by request id in multi-node environment, we need to introduce additional infrastructure (e.g. cache with TTL support) or use sticky sessions, while parameters can be available in the user request.
That is exactly why REST is intended to be stateless.
It would be very beneficial to have stateless pagination option, which won't remove initial search parameters from the next/prev links