>I havn't seen this before but the .pagination.next url value is a great convenience
Reminds me of HATEOAS [0]. Definitely makes it easier to browse using a REST client.
>On the other hand, the OpenAPI documentation doesn't explicitly mention offset and limit for paginated services even though it lists format for each service
I could imagine that they use some kind of middleware for pagination which leads to it not being explicitly included in the OpenAPI spec, especially if they generate it from their DTO classes instead of going API first.
Also, am I the only one who thinks specifying the expected response format via query param is weird and they should just use the Accept header instead? Eh, I guess it’s better supported by OpenAPI.
Yes, I see format in the query string here and there. It is in the medical web service spec FHIR.
* In order to support various implementation limitations, servers SHOULD support the optional _format parameter to specify alternative response formats by their MIME-types. This parameter allows a client to override the accept header value when it is unable to set it correctly due to internal limitations (e.g. XSLT usage).*
Reminds me of HATEOAS [0]. Definitely makes it easier to browse using a REST client.
>On the other hand, the OpenAPI documentation doesn't explicitly mention offset and limit for paginated services even though it lists format for each service
I could imagine that they use some kind of middleware for pagination which leads to it not being explicitly included in the OpenAPI spec, especially if they generate it from their DTO classes instead of going API first.
Also, am I the only one who thinks specifying the expected response format via query param is weird and they should just use the Accept header instead? Eh, I guess it’s better supported by OpenAPI.
[0] https://en.wikipedia.org/wiki/HATEOAS