feat!: Add apiKey support to API requests

[edeandrea]

• Introduced apiKey field for secure authentication in configuration and API requests.
• Updated clear and task APIs to accept enhanced request objects.
• Added required tests and assertions for apiKey handling across all request types.
• Refactored HTTP operations to include apiKey in request headers.
• Introduced new classes for managing authentication details.

Fixes #187

[github-actions]

:java_duke: JaCoCo coverage report

Overall Project	41.83%	🔴

There is no coverage information present for the Files changed

[github-actions]

	Tests	Passed ✅	Skipped	Failed
Gradle Test Results (all modules & JDKs)	636 ran	636 passed	0 skipped	0 failed

Test	Result
No test annotations available

• View Gradle Test Results (all modules & JDKs)

[github-actions]

HTML test reports are available as workflow artifacts (zipped HTML).

• Download: Artifacts for this run

[github-actions]

HTML test reports are available as workflow artifacts (zipped HTML).

• Download: Artifacts for this run

[github-actions]

HTML test reports are available as workflow artifacts (zipped HTML).

• Download: Artifacts for this run

[github-actions]

HTML test reports are available as workflow artifacts (zipped HTML).

• Download: Artifacts for this run

[ThomasVitale]

@edeandrea I'm a bit unsure about the API Key support. Wouldn't that be part of the Docling Client implementation (since it's about establishing the HTTP Client connection) instead of having it included in every API request object?

When I imagine an implementation of DoclingServeClient, I would find it natural to build an instance of the client by specifying URL and optional API Key (from DoclingServeClientBuilder). Then the specific implementation would use the API key in the correct place. I would expect that to be an implementation-specific detail, and the API Key to be a Client concern rather than a Serve API concern.

From a user perspective, especially when using this in the context of a framework like Quarkus or Spring Boot, it means you cannot just inject a DoclingServeApi instance and use it, but you also need to get a hold of the API Key and pass it to every request you make. I would rather have the API Key part of the DoclingServeApi instance built by the framework or via DoclingServeClientBuilder, so that the user can configure the API Key once and not worry about it anymore.

Basically, I think we're missing centralised API Key configuration. What do you think about keeping the Authentication object in Docling Serve Api, but move the responsibility for using it and configuring the API Key to the Docling Serve Client? We could add an authentication() method to the DoclingServeClientBuilder and source the API key from there when building HTTP requests. And remove the AuthenticatedRequest interface.

What do you think?

[edeandrea]

You know what - I think you are 100% correct. The api key should be treated like the base url - a property of the api as a whole, not an individual request.

I'll fix this.

Thank you for catching it.

[edeandrea]

You know what - I think you are 100% correct. The api key should be treated like the base url - a property of the api as a whole, not an individual request.

I'll fix this.

Thank you for catching it.

[ThomasVitale]

No worries :) thanks for looking into this!