I created a library in kotlin that tests if the implementation of a REST-API meets its specification. Feedback is highly appreciated. https://github.com/codecentric/hikaku

I’ll be honest. My initial reaction was ’why?’, but I’m glad I read more. Spring has REST docs and one can easily write tests for verification, but that seems only applicable if you’re not doing Contract first. If you’re doing Contract First, then it’s a lot of extra overhead. I’m definitely going to test this out, and see how it performs vs generating code. As you say, generating code is done to ensure API and model/api stay in sync. But it’s not that much work to update model/API classes by hand when making API changes, and one has to live with extra tools, and potentially ugly code (we’re generating in Java too right now), and potential loss of some of the framework’s capabilities.

Glad to hear you want to give it a try. Let me know your conclusion when you did.

Given it a spin. A nice start. Not sure where you intend to take it. Right now, it appears to require

@ResponseBody

on the functions even though

@RestController

is a Controller with ResponseBody. Not looking at parent class for annotations? That seems to break the produces portion of validation. And it doesn’t do anything with models right now. I know that will be much more work, so wondering if that’s an intended enhancement? Otherwise, I’d be nervous about relying on it as model changes in API and not code would go missed. Or do you generate the model objects still, and just not the API/Controller classes?

Thank you for trying it out and giving me feedback on this. I’ll have a look at the response body. As you said it is actually is a start. I also see the necessity to support models and planned to implement it in the future.

Given that, it’s very promising. I’ll definitely be keeping an eye on it. Still not sure about manually creating/maintaining model objects vs generating them, though. I’m tempted to generate the models, and manually code the APIs. Feels like a good mix, but haven’t thought about it too deeply. Right now, we’re having to put Spring Security scope related annotations on our services because we don’t have access to the @Mapping function directly.