REST service app and exceptions

[allistar]

Hi all,
I am using REST services for a new project. It's all working well apart from that the rest call doesn't provide any information of exceptions that occur. All I get is a general "500" error from IIS with the text "The page cannot be displayed because an internal server error has occurred". Jade is supposed to catch the exception and provide information about the error in the response. I have confirmed that no exception handlers are returning Ex_Abort_Action. I have told IIS not to handle 500 error itself. I have raised this with Jade support but aren't getting very far. I know I can arm a local exception handler myself to deal with this but I'd need to arm it in every rest method which is cumbersome.

Does anyone else use REST services and if so is information about exceptions that occur returned back to the client?

Thanks,
Allistar.
CustomLinc.

[suzuki1100]

Hi Allistar,

Did you get a resolution to your question? Anything from Jade support?
How have you found using the Jade Rest Services? Any limitations or issues?
Performance ok?

We are looking at doing a test/proof of concept of creating a RestAPI using both the Jade Rest framework and ASP.NET core MVC with c# and connecting to a Jade dot net exposure via a repository.
Anyone had experience with this or perhaps WCF or Web API?

[allistar]

Hi Troy,
Getting this to work took a bit of pain, hopefully this helps you out:

- it will only set public properties on the input object in Jade. If you're a good developer like me and make everything protected or read-only, then you'll wonder why the input properties aren't being set.

- if the output format is JSON, exceptions are still serialised as XML in the response. This is a major annoyance as third parties need to deal with this by sniffing the response to see if it's XML. I see no reason why it needs to be this way, but there it is.

- you need new output classes for the ReST response, don't think about using your normal model classes. This is because JADE will serialise every property on the response objects recursively. So only have primitives, or references/collections to other ReST output objects that follow the same rules.

- you cannot inverse the ReST output objects to take care of object deletion. This is because the serialiser tries to serialise the myParent reference and falls over because it's already processed this object. Instead resort to nasty delete/purge code in the delete method, or use the collection the framework provides you for objects you want deleted at the end of the request. All very cumbersome.

- date serialisation doesn't seem to follow standard .NET Date encoding (according to MSDN) but instead seems to be unix encoded.

- if an exception happens the response will correctly be a 500 instead of a 200. The trouble is that IIS hides the actual return from JADE and instead displays its own error file for a 500 response. The trick is to tell IIS to pass-through these errors with this in the web.config file:

Code: Select all

<configuration> <system.webServer> <httpErrors errorMode="Detailed" existingResponse="PassThrough"> <remove statusCode="500" subStatusCode="-1" /> </httpErrors> ...

It took me a while to work that one out. You're welcome

- we do pretty much everything as a POST, not a GET. This breaks the standard ReST conventions but it seems to be standard practice.

- we consume Jade ReST in javascript and also Jade. I had to write a small JSON parser in Jade to handle this. It seems to work well.

- ReST is far easier to test/drive than webservices. You can easily use javascript, node.js, wget, curl, Jade or plain old HTTP requests.

I haven't noticed any performance issues. We handle sessions in an approach you're familiar with: a shared transient token that represents a session, and the key for that token is passed in to every request.

I can't comment on using ASP.NET or C#, adding in more layers doesn't make any sense to me .

Good to talk!
Cheers,
Allistar.

[suzuki1100]

Thanks for the info Allistar appreciated.

- Discovered the object serialisation issue pretty quickly. Ran into issues with mapping methods being invoked on a cloned objects with a read so realized we would have to have another object i.e Value object or DTO which means additional processing overhead

- Found with a GET if we tried to serialise the object ourselves and return a JSON object string, that the string gets all the JSON double quotes escaped, requires preprocessing by users of the api to unescape

- Also annoying that the JSON/XML string sent with a POST or PUT isn't stored and made available nicely. Had to override processRequest() and store and process it ourselves

- Single path url processing is a pain so we would end up having to internally deal with multi level paths e.g. Good Rest URL - GET jadehttp.dll/businesses/Warehouse Ltd/salespersons/Peter Jackson

- Having the application tied to a single JadeRestService class meant we had to process the request and delegate to other transient helper classes to process the request. Otherwise the single class would end up with a huge number of methods

[suzuki1100]

I can't comment on using ASP.NET or C#, adding in more layers doesn't make any sense to me

We wouldn't have to look at c# asp.net core if Jade Rest Services provide the ability to create full modern Restful API's. Right now we would have to write our own custom routing code to deal with multi path.
Given asp.net core provides this out of the box and swagger can create documentation auto-magically as well as the API if you start with swagger we are looking at a Jade dot net exposure.

[allistar]

Hi Troy,
The lack of proper multi-path support is annoying. You can work around this by using IIS rewrite rules. This also allows you to hide the dll from the URL. E.g. a rewrite rule like this:

Code: Select all

<rule name="ReverseProxyInboundRule-twoLayer" patternSyntax="ECMAScript" stopProcessing="true"> <match url="(.*)/(.*)" /> <action type="Rewrite" url="https://webservices.yourcompany.co.nz/somePath/jadehttp.dll/{R:1}_{R:2}?API" /> </rule>

Would take a URL like this:

Code: Select all

http://api.yourcompany.co.nz/accounts/payments.json

And it would call this actual URL:

Code: Select all

https://webservices.yourcompany.co.nz/somePath/jadehttp.dll/accounts_payments.json?API

Which would in turn call the Jade method on your Rest service subclass called:

Code: Select all

postAccounts_payments

The only downside I see is the extra hop the traffic passes through, but it allows you to "hide" the Rest API for multiple end points behind a common single end point which is advantageous. Removing the nastiness of a dll in the URL is also a bonus. This strategy will work for as many layers as you like, so you could go with a URL like this:

Code: Select all

https://api.somewhere.com/version/controller/resource.json

And not be limited to a single path because of Jade limitations. This strategy only works for POST style calls and not GET ReST calls where the number of parameters in the path is flexible.

Regards,
Allistar.