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 (9)

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.

Hello Márcio,


Regarding the subject about the exeception approach, in your logic your able to make a difference between user exceptions (400) and server exceptions (500). Wouldn't this already help regarding giving the correct error messages back in the 'universal api error structure'?


Kind regards,
Evert

Hi @Evert,

The key point to this is to have a centralized point of standardization ( an exception handler that works inside the on response handler) if it doesn't works inside handler we have to make a handler on every exposed action of all apis.

Exceptions not been referable and without data ref will be just generic exceptions between modules.

Action flow copied/cloned between espaces causes the copied flows been incompleted as the exception will not be copied as it is on source action... Leting us looking on every raise on source to see what it was and if we will maintain an exception guided flow creating a new exception and porting magic strings...

This sort of things is what we don't want when writing big erp systems.


Kind regards,

Márcio

Hello Márcio,

Regarding the first item (generic exception handler in OnResponse), how do you imagine this? Since there are multiple status codes (201/204/400/404 etc) which doesn't apply for each API? Think the only one you'll can do there is the 500.


"exceptions not been referable and without data ref will be just generic exceptions between modules."

Don't really agree on this. There is already a difference between DB/security exceptions and you'll can define your own user exceptions (400) in the bl you create.


I know there still can be some improvement, but depeding on how you'll set up you architecture there is no need for copied/cloned flows.


Kind regards,
Evert




views
385
Followers
6