RESTWS-1003: Add /order/validate endpoint to validate order payload without creating resource

[Binayak490-cyber]

Problem

Currently the REST API only validates an Order during creation (POST /order).
This makes it impossible for clients to pre-validate a payload before actually creating the resource.

As discussed in the issue, implementing full validation across multiple workflows would be large and hard to review.
So this PR focuses on a minimal and safe first step — a dedicated /order/validate endpoint.

Solution

Added a new endpoint:

POST /ws/rest/v1/order/validate

The endpoint internally uses the same conversion + validation logic used by the create operation, but does not persist anything.

It:

• Converts the request body using DelegatingCrudResource.convert()
• Returns validation result instead of creating the order

Response Format

Valid payload:

{
  "valid": true,
  "errors": []
}

Invalid payload:

{
  "valid": false,
  "errors": [
    { "message": "Some required properties are missing: encounter" }
  ]
}

Why this approach

This keeps behavior consistent with existing REST validation rules while avoiding duplication of validation logic.
It also keeps the PR small and reviewable, allowing further validation improvements in follow-up PRs.

Testing

Manually tested using Postman with valid and invalid payloads.
The endpoint returns the same validation result as POST /order but without persisting data.

[Binayak490-cyber]

Hi @ibacher, @chibongho,
I have implemented the /rest/v1/order/validate endpoint as discussed.
Would appreciate feedback

[Binayak490-cyber]

Hi @chibongho, @ibacher,
I have implemented the /rest/v1/order/validate endpoint as discussed.
Any further updates for this PR...?

[ibacher]

I was hoping that this was integrated into the existing OrderResource and not just adding a new dangling endpoint / controller.

[Binayak490-cyber]

I was hoping that this was integrated into the existing OrderResource and not just adding a new dangling endpoint / controller.

Okk @ibacher, agreed this to live within OrderResource rather than as a separate endpoint.
Before refactoring, I just want to confirm the preferred pattern: would you like this exposed as an action on the existing resource (e.g. POST /order?action=validate) similar to other RESTWS actions, or is there another established approach in this module for validation-only operations?

I want to make sure the implementation follows the intended REST conventions before updating the PR.