Posting JSON to a Restful WCF service

This should be simple, but WCF isn't very forthcoming when it comes to deserialization errors.


To get this working with an out-of-the-box .Net 4 Rest WCF service:

1. Start Fiddler.
2. Go to Fiddler's Request Builder, and select the Raw tab.
3. Establish the POST URI, and the format of the POST data (this will be shown on the service's help page).
4. Copy, paste and edit the below sample request.
5. Execute the request.

Points to note:

1. The POST address must end in a slash: http://localhost:57036/endpoint/.
2. The Content-Type must be set to application/json.
3. The Content-Length must be match the size of the body.
4. The body's format must be the correct JSON representation of the object. If in doubt check the service's help page.

Making a Restful WCF service vary its response

A natural fit with the HTTP architecture is to have a WCF service vary the response contents according to the MIME type set in the Accept header by the client.

Whilst this is easy to do using the WCF Web API, it is slightly more challenging in an application using regular WCF (even WCF 4).

The specific scenario I needed to handle was:

1. Given a request for a resource.
2. When the Accept header is not set, respond with the appropriate default representation (e.g. XML/JSON object).
3. When the Accept header is set to a relevant MIME type, e.g. application/png, respond with a stream containing the PNG representation of the resource.
4. Due to the architecture being used, the method's response type could not be the Message type, but had to be that which represented the default resource representation.

The solution I finally arrived at was greatly added by this great post on IOperationBehaviour and the WCF Web API PngResponseFormatter. A sample solution can be downloaded as a zipped VS 2010 solution.

Calling one WCF service from another

Over a year ago I hit this problem, and no amount of work would fix it. A year later, having found myself facing it again, I finally found the solution, thanks to this post.

Whilst the solution was simple, I've written my services so they can be unit-tested. Hence references to instances that require the presence of an HttpRequest are not allowed.

The picture below shows my eventual solution. Whilst it has a large number of classes/interfaces, they are each very small and focussed. They combine together extremely well to allow one service to call another, using Inversion of Control to access the child-service's client.

From Tiny drops of knowledge

Hiding the WCF .svc extension on IIS 5 or 6

If you're setting up a WCF web service, its nicer to present a URL that does not have the .svc extension in it, i.e.

http://moviesite.com/movies/123

Instead of
http://moviesite.com/service.svc/movies/123


A simple way of achieving this on IIS versions 5 or 6 is using the free ISAPI Rewrite tool, with the following configuration:

# Don't rewrite url's that already contain .svc.


RewriteRule .*\.svc.* - [L]


# Rewrite requests for host moviesite.com to be moviesite.com/service.svc/whatever.

RewriteCond %{HTTP:Host} moviesite.com

RewriteRule ^/(.*)$ /service.svc/$1 [L]

Load testing a WCF web-service gives a 403 error on IIS 5.1 (XP Pro)

If you're hosting a WCF web service using XP Pro's IIS and checking its thread-safety by hitting with > 20 threads, then its likely you'll be seeing some 403 errors.

This is unfortunately by design. See Jeff Atwood's article on why and how to get around IIS 5.1's shackles.