6
 Followers
11
 Likes

Enable changing of rest api response out off the OnResponse handler

Integration
New

We are facing many blocking issues trying surpass the default limitations of rest api on exception handling and standardization of responses.

I have related all the scenário on this other idea where I'm suggesting to free some of the blocking issues we are facing.

https://www.outsystems.com/ideas/6943/add-exception-handling-on-exposed-rest-api


To be more precise here I will paste some of the content, as all of issues are blocking some solution.


The lack of not having an error handler on exposed rest api block us on having a decent exception handling on rest api.

In our case we are trying to implement and harmonize the behavior of our web apis on many platforms in many ways as:

The standardization of responses and exception handling not only to status codes but the standardization of json structure of validations and error handling.

Said that, we tried many things, all finding any sort of Outsystems limitations.

PS: We don'twant to do manual validation on all our actions and raise exceptions after manually change the status codes and duplicate the exception messages. It open for many breaks to standardization and falls in the message duplication of exceptions in OS as stated below.


The exception approach:

Exceptions in OS:

Can't be public and can't be referenced between modules;

Need to specify a exception message on all raises, causing non standardization and duplication

Need duplication and I think duplicated one aren't caught on specific handlers with same name, only generic ones;

Almost ten years ago Gonçalo Borrêga already suggested changes on this: https://www.outsystems.com/ideas/100/Allow+custom+Exceptions+to+be+public+and+referenced+from+other+espaces?IsFromAdvancedSearch=True

The default built-in exception handler of rest api returns almost all time a status code 500. Not the more adequate.

Second try:

Tried to use exception handlers in OnResponse rest api handler:

But when it runs, the exception handler never runs;

I made some helper actions on a helper module to get the standardization of status codes.

With the helper centralized actions I could standardize the status codes at least, but can't make any sort of data validation exchange between action and handler, as there is no way to pass data do the handler nor made any changes to response out of the OnResponse handler. Then my Bad Request scenarios are not solved by this approach.


At this point I can't detail to the client of my apis what not passed the validations.

To complete this, the use of structures as parameters on api doesn't have mandatory and data type validations!

I will cover all of the lacks on individual ideas and a forum post with all of it.

Hope someone else can converge on need for some changes on this.

Márcio.

Created on 17 Jun
Comments (6)

Changed the category to Integration


Merged this idea with 'Add exception handling on exposed rest api' (created on 17 Jun 2019 13:34:36 by Márcio Mônego Fonseca)

The lack of not having an error handler on exposed rest api block us on having a decent exception handling on rest api.

In our case we are trying to implement and harmonize the behavior of our web apis on many platforms in many ways as:

The standardization of responses and exception handling not only to status codes but the standardization of json structure of validations and error handling.

Said that, we tried many things, all finding any sort of Outsystems limitations.

PS: We don'twant to do manual validation on all our actions and raise exceptions after manually change the status codes and duplicate the exception messages. It open for many breaks to standardization and falls in the message duplication of exceptions in OS as stated below.


The exception approach:

Exceptions in OS:

Can't be public and can't be referenced between modules;

Need to specify a exception message on all raises, causing non standardization and duplication

Need duplication and I think duplicated one aren't caught on specific handlers with same name, only generic ones;

Almost ten years ago Gonçalo Borrêga already suggested changes on this: https://www.outsystems.com/ideas/100/Allow+custom+Exceptions+to+be+public+and+referenced+from+other+espaces?IsFromAdvancedSearch=True

The default built-in exception handler of rest api returns almost all time a status code 500. Not the more adequate.

Second try:

Tried to use exception handlers in OnResponse rest api handler:

But when it runs, the exception handler never runs;

I made some helper actions on a helper module to get the standardization of status codes.

With the helper centralized actions I could standardize the status codes at least, but can't make any sort of data validation exchange between action and handler, as there is no way to pass data do the handler nor made any changes to response out of the OnResponse handler. Then my Bad Request scenarios are not solved by this approach.


At this point I can't detail to the client of my apis what not passed the validations.

To complete this, the use of structures as parameters on api doesn't have mandatory and data type validations!

I will cover all of the lacks on individual ideas and a forum post with all of it.

Hope someone else can converge on need for some changes on this.

Márcio.



This comment was:
- originally posted on idea 'Add exception handling on exposed rest api' (created on 17 Jun 2019 by Márcio Mônego Fonseca)
- merged to idea 'Enable changing of rest api response out off the OnResponse handler' on 19 Aug 2019 10:56:40 by Fernando Moitinho

Changed the category to Backend




This comment was:
- originally posted on idea 'Add exception handling on exposed rest api' (created on 17 Jun 2019 by Márcio Mônego Fonseca)
- merged to idea 'Enable changing of rest api response out off the OnResponse handler' on 19 Aug 2019 10:56:41 by Fernando Moitinho

Can we have a new hope on some of this?

Hi Márcio,

At this stage, we are still looking into the problem. 

At this point we do believe that adding this into the product would bring extra complexity, however even though it is possible to customized the response status code, this is not reflected in the auto-generated documentation, which can be misleading when used as a form of communication between different development teams.

Thanks for your feedback.

views
266
Followers
6