These aren’t in the order I learned them. They’re not in the order of importance, either. They are in order, though.
- Even if you plan on running it under IIS, do the development with the dev server built-in to VS (Cassini)
- There’s lots of little problems you may hit running under IIS, so having it working under Cassini first lets you know which problems are caused by IIS config 🙂
- Cassini (at least in my 2010 RC) only binds to 127.0.0.1 / IPv4 when it does its localhost binding, not ::1 / IPv6
- Chrome doesn’t display xml response nicely like IE does – appears to try to render it as html.
- Content type response header was application/xml; charset=utf-8, so it kind of surprised me that it didn’t render to something friendlier.
- version of “184.108.40.206 (38071)” (stable branch)
- Under IIS, WebDAV by default includes a lot of verbs that it handles for all extensions.
- In inetmgr, Handler mappings -> WebDAV -> Request Restrictions -> Verbs
- Since that list includes PUT and DELETE by default, if GET and POST work fine but those 2 don’t, that’s one thing to check.
- Simplest fix is to fire up appwiz.cpl and get rid of WebDAV, although you could just remove those 2 verbs from the list if you wanted. Of course, doing so you’d presumably break WebDAV clients, so I’m not sure that’s of any real value 🙂
- Much like WebDAV, the asp.net compat settings, like [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] and <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>, may break certain verbs like PUT and DELETE for non-obvious reasons.
- If you don’t need them, don’t use them, of course 🙂
- You don’t have to use an interface for your service contract, it can be on the real implementation class (tons of examples do this), but if you want to have consumers use WebChannelFactory, you need an interface.
- On a related note, I apparently wish “where T is an interface” was a viable generic constraint, since that would have been nice in this case instead of hitting it at runtime 🙂
- I really liked putting the ServiceContract/OperationContract/WebGet/WebInvoke attributes in the interface to make the implementation class a little cleaner.
- Certainly makes sense to have them there given the client consumption 🙂
- It makes me sad that UriTemplate only supports string as the type if the template part being matched is a path segment.
- It can map other types (int, long, etc) if it’s in a query string, but I’d rather do the Convert call myself than make (IMHO) uglier access URI’s 🙂
- If you’re using something ‘manual’ like Fiddler’s Request Builder for making your REST calls, you actually get a pretty decent error message in the body of the 400 Bad Request response:
- The incoming message has an unexpected message format ‘Raw’. The expected message formats for the operation are ‘Xml’, ‘Json’. This can be because a WebContentTypeMapper has not been configured on the binding. See the documentation of WebContentTypeMapper for more details.
- Reminded me to add Content-Type: text/xml and then it was happy 🙂
- The WCF Test Client that gets run if your svc is set as your startup page will still query for WSDL and complain that it can’t find metadata for your service.
- The WCF REST Starter Kit for 3.5 is great, but it hasn’t been / won’t be updated for 4.0.
- The one thing it was nice to see that made it back into the framework in 4.0 was automatic generation of a REST service’s help page via <webHttp helpEnabled="true" />
- Not clear off-hand what the help page lacks for generation of a proxy similar to SOAP/WSDL, but I haven’t dug into it, either. It sure looks like nicely structured, but perhaps there’s some metadata not getting exposed there.
I have not failed, I’ve just found 10,000 ways that won’t work.