It is possible create a Rest WS without */rest/* in the URL

Hi guys 


When we have that really strange observations from a client about our application design: 

Per default Outsystems creates Rest WS with */rest/* in the URL

It is possible to remove it (*/rest/*) 

https://success.outsystems.com/Documentation/10/Extensibility_and_Integration/REST/Expose_REST_APIs/Customize_REST_URLs


I think no. But is just to be sure and tell them.


Thank you,


Kind regards,

Nuno Oliveira

Solution

Hi Nuno,


It is not. The customization part always start after the /rest/

For more than that you will need a proxy in front of the platform if you really need to do it.


Regards,

João Rosado

Solution

João Rosado wrote:

Hi Nuno,


It is not. The customization part always start after the /rest/

For more than that you will need a proxy in front of the platform if you really need to do it.


Regards,

João Rosado


Thanks João Rosado for replying.

You could look at using the SEO URL mapping in service center, it may let you map a different URL to the same endpoint.

Warning: The SEO URL feature is not meant for that. It's only purpose is for web screens to help on search engine optimization. Everything else is really not recommended.

The Redirect Rules part of the SEO settings works perfectly well for this sort of things with web pages and simply uses the IIS (in .net system away) redirect rule. I haven't tried it specifically with REST calls so it would need to be tested and possibly the redirection process might break the REST call but I don't see why trying it would be a problem if he really needed to remove the /rest/

EDIT - I just did a test specifically with a REST endpoint and it works very well. I would however only use it if you really needed to as it adds a http redirect step to your request and is therefore not as efficient

EDIT 2 - But it is a very legitimate usage if you change your API endpoint and need to keep the old address available for other systems that are configured for the old address, in fact thats the type of thing that the redirect rule was originally made for. Also very useful where you create versioned rest endpoints with different names over time (ie /REST_V10, /REST_V20 etc) but also need a generic endpoint name that always points to the most current version (ie /REST_CURRENT -> /REST_V20).

Probably is worth noting though that the documentation function of the rest endpoint will show the real URL not the redirect setup. 

I know it partially works. But It's not the correct usage of the SEO URLs feature.

Even the argument that you can use it to keep an old url, that is also meant only for search engine purposes (so that the old links does not lose the rating on engines). It is not designed to keep integrations compatibility.

Any issue regarding not SEO related usage of the feature is being handled as not supported and there is no guarantee that will continue to work correctly in future versions.


Regards,
João Rosado

From Outsystems own documentation on the redirect rule. It is not intended only for SEO but where the domain, (and by extension parts of the domain) change and you want to allow the old references to work.


https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/OutSystems_Platform_SEO_Friendly_URLs


That sentence is exactly what I was talking about on my previous post. You are reading too much into it.

"URL References" is only meant to refer to Web Screens and the rest of the sentence is obviously talking about search engines ranking.


But since you mentioned the redirect rules as an example, that is exactly one of the things that won't work correctly in REST.
Those Redirects (301 or 302) won't work with any REST action with POST requests. Since according to the HTTP spec it requires a 307 redirect to maintain the body of the original request. Otherwise the body gets discarded and the request usually gets converted internally to a GET by most frameworks causing errors.


Ok yes I stand corrected, a REST POST call does get changed to a GET as part of the redirect so GET will work but POST won't