REST Expose: response type for each http status code

Not right now

It would be great if OutSystems exposed REST APIs supported multiple response types, instead of just one type (structure).

In swagger, you can set a response type for each status code and have different structures for each one and all the different outputs are then properly documented.

Something like this:

          description: An array of products
            type: array
              $ref: '#/definitions/Product'

          description: Unexpected error
            $ref: '#/definitions/Error'

This would give:

- more flexibility when creating exposed REST APIs;

- multiple response types support in the "OutSystems way";

- better documentation, including all the response types available;

Created on 6 Feb 2017
Comments (3)

Hi Carlos,

You can do it. Check the documentation: https://success.outsystems.com/Documentation/10/Extensibility_and_Integration/REST/Expose_REST_APIs/Expose_a_REST_API

Using what is described in the article above to set the status code and the OnResponse extensibility point you can to set the response text. Unfortunately, this won't reflect in the swagger documentation though.

Hi André,

I know you can do it, but not in an explicit way.

With the SetStatusCode you can output another status code rather than 200, but this is done on the web method logic. But, you can only set one output structure for the code 200 explicitly in the web method output. You can only have one output parameter set to send in the body.

I would like something like this:

Another problem, is that because you only set the other status codes in the web method logic, they are not visible in the API documentation. The documentation only shows the status code 200 and the default output structure.

The idea is to also show in the documentation all the status codes that the web method can output and the different structures each one can output, like swagger does.

Changed the status to
Not right now

Hi Carlos 

Sorry for the late reply, but we are not planning on delivering this in the near future.

Although this makes sense, with the upcoming new features that we have in mind we currently don't have plans to tackle this in the near future.

Nonetheless, thank you very much for your idea and keep it coming.

If you believe we missed some context that would change our perception about it, please give us more details about why you would need this and for what is the use case.