I am updating this idea to hopefully get the additional motivation to move this idea from "Not right now" to "Working on it".

Please advise If a new idea is needed.

OutSystems support has confirmed that the REST URL Path is a limitation of Service Studio and that the limitation is not described in the documentation.

The situation has already been reported to the R&D team in order to review the documentation and add all the URL Path constraints in Service Studio. 

Based on the use case that I presented to support they reported this improvement suggestion to the R&D teams for further evaluation.

When a hyphen (-) is used in the custom `URL Path` property of an exposed REST method.

Invalid URL Path
 Invalid URL characters in property 'URL Path' of the 'CustomURLPath_GET' REST API method.

Is this behaviour correct or a potential bug?

There is no detail on the Invalid URL Path Error page for this error and this use case is not covered in the Customize REST URLs page.

My view is that the hyphen should not cause an issue in the `URL Path` based on the subsequent ramble.

The `URL Path` property is a "Customized URL for the method. Use it in order to follow RESTful principles identified by your organization.".

An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

It is my understanding that the ServiceStudio `URL Path` property relates to the /<path> component.

Within the /<path> component, "/", ";", "?" are reserved. 

The "/" character may be used within HTTP to designate a hierarchical structure.

The "{" and "}" are used in the ServiceStudio `URL Path` property to designate an input variable to the method.

The "-" is a restricted character in ServiceStudio for `Name` properties.

Therefore, the hyphen should not break `URL Path` property. 

Hi Ouen,

I think it is clear that it is a limitation.

The workaround I have seen for this situations is having a Service manager (and with it a new license the final customer has to pay) in between OutSystems and the caller doing the translation. It does not make sense to have to do this but it was the workaround I have seen in place for this situation and also for the PATCH limitation.

Being that said, I also would like to think OutSystems would reconsider the non-development of this limitation.

Cheers,

João 

Hi João ,

That option does make sense for an on-premise installation of the platform.

Do you have any recommendations or ideas for a similar solution on the OutSystems Cloud-hosted platform?

Thanks
Ouen

Hi Ouen,

The solution I mentioned would still work on the OutSystems Cloud, you would need to have the API manager hosted somewhere else indeed (in a server on-premise or in the API manager cloud, this would depend on the API manager).

Basically you would need to select an API manager (e.g. API Gee), set it up and set up a service with a name with the "-" which then forward this to the correspondent in OutSystems without the "-". The API manager service (with the "-") will be the entrypoint for the external world.

As I mentioned, this was a workaround applied in a previous experience but of course customers are not eager to take the costs of another server and another license to workaround this OutSystems limitation.

Best regards,

João Marques

Hi guys,

I was thinking about this, and another option could be to inject the hyphen as an url parameter, when creating the mock. 

This is probably only useful for the test scenario, unless there's some way to sanitize the input before the request - but it can potentially be  a workaround without the need for an external service. 

The endpoint will work with the hyphen, but also with a full encyclopedia text :D

The following responds to /hyphen-test, the input parameter is of type text:

I also think this should definitely be addressed by outsystems.