Add statement about of Pageable to documentation

[terribleherbst]

Setup information hikaku version: 2.0.0-SNAPSHOT implementation converter: SpringConverter

Describe the bug Spring data supports the idea of Pageable. A pageable is an object build by request parameter, supporting page, size and sort (parameter names are changeable). These parameters might be part of an api, but are not explizit mapped to query parameter. The documentation says "Query Parameter based on an object" are not supported, but I think a Pageable should be mentioned explizitly.

Expected behavior Add support for Pageable or add a note that Pageable are currently not supported in hikaku.

Code samples: Can you provide specifications or code snippets?

public ResponseEntity<Person> getPersons(
        @RequestParam(name = "language", required = false) String language,
        @PageableDefault Pageable pageable) {
...
}

[cc-jhr]

Note: Both interface and annotation are provided by org.springframework.data:spring-data-rest-core

[jrehwaldt]

I'd like to see something like this as well, but not specific for Pageable. We implemented our own HandlerMethodArgumentResolver (I think Spring Data does the same for Pageable), which takes a request and creates instances that may be used as controller method arguments.

What I'd like to see is a HikakuConfig taking a list of something like DifferenceEvaluator from XmlUnit. Each spotted difference is passed through all DifferenceEvalutators and can be altered there. This way, a PagaeableDifferenceEvaluator would be written that checks if Pageable is a method argument when the spec requires the three query parameters page, size and sort.

What do you guys think?

Edit: Actually, all current ignoreXxx config options could be easily implemented this way.

[cc-jhr]

Hi @jrehwaldt, thank you for giving feedback on this topic.

First of all, as stated in the list of currently not supported features in the README.md of the spring converter, query parameter based on classes/interfaces are currently not supported in general. So depending on the solution for that, this might solve the cases mentioned above already. It might make sense to implement the general approach before we focus on specific interfaces or classes.

From my perspective the PagaeableDifferenceEvaluator idea wouldn't work. Hikaku is designed to convert a specification or an implementation to an internal domain model of a REST endpoint. After that the model for the specification is compared to the model of the implementation in the core. At the time of the actual comparison, there is therefore no additional information about the implementation, such as class types and the like. This is intentional.

However I like the idea of creating rules dynamically for the config to ignore specific bits, instead of static rules.

[cc-jhr]

Created an issue for the general case. See #47

[jrehwaldt]

As I see it the proposal from #47 unfortunately doesn't solve either the general nor the original issue.

• Pageable is an interface, which you excluded from your proposal
• The proposal assumes a strict mapping from query parameter to an object property, but the latter should be an implementation detail and not bound to external names. Imho, a query parameter sort could be mapped to sortOrder internally.

A truly general solution would be to allow deriving arbitrary parameters from unknown objects declared in endpoint mappings, something like (Object) -> Set<Parameter>, with Parameter being any of these.