REST service app and exceptions

The use of specific JADE features and proposals for new feature suggestions
allistar
Posts: 129
Joined: Fri Aug 14, 2009 11:02 am
Location: Mount Maunganui, Tauranga

REST service app and exceptions

Postby allistar » Fri Dec 02, 2016 3:32 pm

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.

User avatar
suzuki1100
Posts: 17
Joined: Tue Nov 24, 2009 12:00 pm
Location: Auckland

Re: REST service app and exceptions

Postby suzuki1100 » Tue May 02, 2017 9:37 pm

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
Posts: 129
Joined: Fri Aug 14, 2009 11:02 am
Location: Mount Maunganui, Tauranga

Re: REST service app and exceptions

Postby allistar » Wed May 03, 2017 11:40 pm

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.

User avatar
suzuki1100
Posts: 17
Joined: Tue Nov 24, 2009 12:00 pm
Location: Auckland

Re: REST service app and exceptions

Postby suzuki1100 » Thu May 04, 2017 12:57 pm

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

User avatar
suzuki1100
Posts: 17
Joined: Tue Nov 24, 2009 12:00 pm
Location: Auckland

Re: REST service app and exceptions

Postby suzuki1100 » Mon May 15, 2017 9:34 pm

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.


Return to “Feature Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest