Expose REST web service: Add versioning control

By Robert Chanphakeo on 19 Oct 2015
An exposed REST web service is consumed by various applications (mostly external applications).

Since we do not have control over external applications consuming our REST web service - changing an existing web service will often break existing consumer applications, there is a need for versioning control! 

Learn from www.stripe.com and add the ability to publish multiple versions of a RESTful web service, where multiple versions of a web service is able to operate all at once.

Current work-around solution: clone eSpace, make changes to new eSpace, publish eSpace as a new version.
Couldn't you receive an an Accept header in the HTTP request and then parse it in the REST method.

Based on the accepted version you could execute a different logic.

You would accomplish a scenario with same interface and different behaviors.

Yes, you can accept version in header, however you are unable to version outsystems structure.

current work around solution is to clone the espace for each new version changes you make.

Example
domain.com/v1
domain.com/v2
True.

In a scenario where new versions require different interfaces either we use a generic input (which subverts the platform behavior) or we endup cloning either the espace or creating a new REST API (which is what I normally do).
problem with creating a new REST api is it can not be in the same espace, so we have to clone it, we can't have two structure with the same name. why not introduce namespace? or folders for structures, this is so we can have a structure with the same name for different versions of our api.