Expose Service Action as public REST APIs


New on version 11 it's the possibility to create Service Actions that actually are used internally as REST APIs to be used in other modules of the infrastructure

It should be possible to make those Service Action as public REST APIs, for instance adding a new property, either Public or Expose REST API to allow other systems to use this in a true microservices way:

Created on 24 Oct 2018
Comments (6)

Changed the category to Backend

Hi Pedro Coelho,

Thanks for your feedback!

If you want to have public REST API you can use the platform REST capabilities under the "Integration" folder.

In this case, why do you want to make Service Actions "public to the world"?

I would like to better understand your use case.


Hi Pedro,

A couple of things that we automated on these Service Actions aren't directly portable to public facing REST APIs. This means that the developer has some decisions to make for the REST APIs like for instance what type of authentication mechanism is used, who has access to this REST API and how to track it, how to map (if needed) external access to users in the platform, etc.

But there's a path for you to expose your microservices internally and externally considering what I mentioned above. The most productive way to do it would be to centralize the business logic of the microservice in a Server Action and then reuse it both in a Service Action for internal microservices and in an exposed REST API for external microservices, adding any specifics that each interface may require.

Does this make sense to you?

Yes André it does, and that is the way I've used it, I see vantages in that approach (like versioning for instance) but I can foresee issues with that approach also (like forgetting to change the REST API contract and it still works because the changes that you made aren't explicitly breaking anything for instance)

The idea was to have those basic options available (including authentication, same as a normal REST API) but just done automatically and always keep in sync the code, which will most likely meet more than 95% of the usage for this scenario.

This would be the built one reuse always philosophy, either the reuse is internal or not

Nuno Maurício

The use case is to actually achieve microservices architecture using the newly created features.

If the platform internally creates a REST call to a service action instead of using the dll generated code that it would use if you were referencing an action (including all of the internal security and all of that in the mix), it's just a matter of adding the other layer required for a "regular" REST method that is kept in sync (documentation wise, contract, etc.) with what as built 

Thanks, Pedro.

Actually, that "sync" that you mention is one of the tricky parts. 

As you may know, REST doesn't have a "contract" and because of that, we are unable to understand how the "outside world" is using our Service Actions, making the Impact Analysis impossible.

The outside World doesn't also know the users in the environment which makes the Authentication part useless as well. 

When it comes to Discoverability, since the REST APIs doesn't have a contract, it is very difficult to understand the method "signature" so that we can map the parameters.

For "outside world" REST capabilities, OutSystems provides the Integration one which does not have this "goodies" that I consider awesome in Service Actions. 

If you want to combine Service Actions with REST APIs, that's up to you and I believe that it is a good idea so that you can have a mixed authentication process and impact analysis for Service Actions. If you change a Service Action, your public REST API should be impacted as well and you'll make the needed changes that I believe that it would not be that disruptive.

Hope it clarifies your request. I'm not saying that it is useless, not at all. Your idea is valuable but we (or REST) are not in a stage that we are able to fulfill it.