Hi Konstantinos, hi all,

I agree with the concern that using export="true" could
unintentionally expose services.

Both approaches you propose are fine with me: either introducing a
dedicated export-api="true" attribute or removing the feature
altogether.

However, one point I'd like to add is that, regardless of the removal
of the 'action' attribute by Deepak, using export="true" has never
really allowed the creation of a REST API in the architectural sense.
With that approach, you expose individual service definitions, but you
can't model a single endpoint as a resource and use the different HTTP
methods (GET, POST, PUT, DELETE, etc.) to operate on that resource.

Simply changing the name of the attribute to 'export-api' doesn't
fundamentally change the fact that this mechanism is not sufficient
for properly designing RESTful, resource-oriented APIs.

Regards

Anahita

Il giorno mar 28 lug 2026 alle ore 21:59 Konstantinos Marinos
<[email protected]> ha scritto:
>
> Hi all,
>
> I was hoping to start a discussion about the current interaction of setting
> export="true" in a service definition in regards to the recently added
> rest-api module in the framework. The same flag that existed before
> (export="true") now additionally exposes a service definition as a REST
> endpoint. This is one of the ways to create a REST endpoint (the other
> major one being a *.rest.xml definition file) but since the component is
> now part of the framework, this could have unintended consequences.
>
> My biggest concern is that developers might not immediately realise that
> this one flag is used for similar but distinct use cases and this might not
> be the desired behaviour for all new or previously exported services.
>
> In order to avoid implicitly exposing services with potentially unintended
> consequences, I am reaching out for your thoughts on the following
> alternative actions:
>
> * We remove the feature of defining REST endpoints in this matter
> completely. Previously existing usages of export="true" remain unaffected
> and REST endpoints can be defined by dedicated rest.xml files.
>
> * We create a separate flag in the service definition (e.g.
> export-api="true") that only controls the auto discovery and creation of
> these REST endpoints. The two export features are then decoupled from each
> other and by setting the new flag in the service definition, clear intent
> is communicated by the developers.
>
> What do you think about these two options?
>
> If you are already using this feature to create REST endpoints or plan to
> use it in the future, please let me know as well, as it would mean that the
> second option has merit and it is the least destructive change of the two.
>
> Thank you and best regards,
> Konstantinos Marinos

Reply via email to