Today a really quick post on a very specific thing that can simplify your code a lot.
Let’s assume that we need to reach to some webservice but really it is optional in our business logic. Real life example might be some config data that you take from it but equally you have your defaults that are also acceptable.
When standard HTTP requester fails you have an exception thrown that you can catch in you error handling strategy. But that breaks execution of your flow and you do not want that. How to make it fail safe?
On second tab of HTTP request component you will find validator setting. That is what you can use to make it fail safe. You just add http statuses that will be interpreted as succesful response codes. But which codes are success for me to make it fail safe? Easier said than done I guess. Should you enter all possible statuses? There are many factors that you must consider here.
First let’s have a look at HTTP statuses on Wiki. Actually there are 3 groups of codes that you can get in response from webservice.
2xx – are success codes. It is happy path when you get that. It should be accompanied by correct response body that you expect.
4xx – are client side errors. Your request is deemed as incorrect by the webservice. Among them you will find authorizations, invalid request errors and famous 404. Basically your requests should always be correct and you want to know when they are not to fix them. So if authorization or request breaks in the future maybe it is not a good idea to add these codes to success path? If you do – you will never know that you have this kind of problem. 404 might be the only exception – when a resource does not exist (and that can happen when you use a URI parameter as well) then it means you need to fall back to defaults.
5xx – are server side errors. You cannot do anything about it but only retry (Until Succesful scope to the rescue) if it makes sense. It is not a good candidate in our fail safe strategy.
Second thing you need to consider is webservice documentation.
When you reach a mature public API usually you will find in docs all possible response codes including 4xx errors. But in my experience I needed to use (or reuse) a lot of APIs where 4xx errors docs were a rare bird especially when you go beyond standard API Kit Router error handling. In all cases I always go into testing how the API actually behaves. For instance I test what happens when you reach for product code (in URI) that does not exist. Is that 404 error (that I would implement personally) or some 5xx nasty internal server error or just 2xx and empty response. Proper 404 for not existing URI params is the most neglected.
In my project I needed to get a file from Shopify API that would contain setup that can be used in further processing. It is not always there, if not one step in processing will be omitted.
Shopify API is one of the best I have worked with so far. Very consistent, reliable, well documented. Status codes are used as documented and according to best practise. It is first API that I saw 422 error in action…
Flow for reading masterdata is quite straightforward. There is some complexity added to make it flexible and completely switch the logic off depending on property (the first choice router). Then the HTTP requester comes on stage and depending on response the file is processed or just empty collection is returned from the flow.
Config file is stored using Asset object. When querying for not existing object I will get 404 error. That is something I would expect.
In validator config I set two response codes only. One is for happy path and the other for not found (404). If there is any any other error I want to know about it, i.e. I want exception to be thrown and processed by my exception handling strategy. And that will create a error ticket for my 2nd line of support.
After I succesfully requested for my config file it is time to sort out whether it is a file or 404. In second Choice Router that condition is checked and adequate path is chosen. When response is 404 only empty collection is set as payload and returned from the flow.
Worth mentioning is that any 4xx or 5xx error will cause Until Succesfull Scope to kick in and it will retry requests according to retries setup. That makes sense because Shopify from time to time can have issues or we might have intermitent network issues so retry can sometimes help.
And regarding other 4xx errors – I want to know about them. My golden rule here is – it might happen that the file is not there but if it is – it should be picked up.