This question is geared more towards anyone that does custom API development. We have MANY jobs that run through our custom API coding, and when one errors out, all I get in return is a generic error. In that error, I also am returning the full url for the GET, POST, PUT, etc. When I run this URL in Postman, I am able to actually get an informative error message that will tell me exactly what the issue is. For example, this is the error returned from my .NET code -
The remote server returned an error: (422) Unprocessable Entity. But then when I run the URL in Postman, it will tell me that there is an invalid field name. I have debugged while capturing an error, and I have inspected the exception that is caught in my try/catch block. I don't see any messages that resemble what is returned from Postman. Has anyone successfully retrieved a worthwhile error message from your custom .NET API code? Thanks, Kevin Kevin Jesik | Information Technology | I.T. Application Developer Denver Water | t: (303-628-6283) | http://www.denverwater.org | Kevin.Jesik@denverwater.org
Hi Kevin, Hmm. Having reinstated my Global Discussion Real Time Alerts after a brief hiatus, this is turning into a bit of a Misery Loves Company morning for me, but so be it... Yes, to confirm, in .NET (et al), the best we've been able to pull back through .NET from the API are very generic errors, making it VERY tough to gracefully recover in certain situations. It has ever been thus, and we've had many discussions with Workfront over the years (we started at v2.0; now v10.0+) seeking to improve the granularity (e.g. more like Postman reports) and consistency (e.g. sometimes we get HTML back, vs a REST response). One very common usecase that causes grief is: given a DE:CustomParm, should it be renamed (e.g. to DE:SameParmNewName) or deleted, a previously working request for DE:CustomerParm errors out in a way that is impossible to Catch, leading to immediate failure and outages. We mitigate that risk using education and limited security access to make such change/deletions, but it still happens. Earlier this week, in fact, we spec'd out a new approach to insulate us from this risk, which -- although expensive do develop -- we've decided to invest in, as more and more clients rely on our "https://store.atappstore.com/" solutions . Once that's in place, we'll have worked around this particular usecase, but would of course still appreciate any broader plumbing improvements Workfront can provide to the API error handling. So: in short, no joy yet, but hope springs eternal. Regards, Doug Doug Den Hoed - AtAppStore [Company] email@example.com
Thank you Doug for the reply. Very much appreciated! Kevin Jesik | Information Technology | I.T. Application Developer Denver Water | t: (303-628-6283) | http://www.denverwater.org | Kevin.Jesik@denverwater.org Past, present and future: Water connects us all. 1918 - 2018 Subscribe to TAP to hydrate your mind , and follow us on Facebook, Twitter & Instagram.
Hi @Kevin Jesik and @Doug Den Hoed - AtAppStore - I don't use .net and haven't run into this issue specifically. Putting what you're saying into other terminology, it looks like .net is only presenting you the 'Status Code', which in your example is the 422 code. However, what you really need is in the JSON body (path = error.message). This is already returned by Workfront's API. An example is below, as presented in Microsoft LogicApps.
I think this is more a question for a .net developer forum to see whether there is a way of exposing the response body. I would think it should be possible. While searching, I came across a similar discussion on another product's forum, where it looks like it ended up as being a feature request to expose the response body: "https://discuss.newrelic.com/t/feature-idea-surface-additional-details-in-error-analytics-with-http-response-codes/39750/4" https://discuss.newrelic.com/t/feature-idea-surface-additional-details-in-error-analytics-with-http-... Sorry I can't be more use but hopefully this helps shed some light. David Cornwell
Thanks David -- above and beyond, as always. I think you're spot on, and -- since the desired message is obviously nearby (in the body) -- expect that once this does make it into an API Improvement sprint, it should be a relatively easy lift. Regards, Doug Doug Den Hoed - AtAppStore
Hi Kevin and David, Just to follow up on the renamed/deleted parameter conundrum that I mentioned... The root cause of the problem for us (in .NET, etc) is that in such cases, the API (falsely) returns a message of "200 OK" with an empty "data" payload; and with that misleading "OK", our code presses on blindly, then pratfalls on the (unexpected) empty data. Regards, Doug Doug Den Hoed - AtAppStore