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
<httpErrors errorMode="Detailed" existingResponse="PassThrough">
<remove statusCode="500" subStatusCode="-1" />
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.
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!