Tag Archives: rest

#REST-ish API with #WCF, part 2 Responses

If you thought the headache was over, I’ve got a treat for you. It’s not. But the “solution” isn’t far away though and quite straight forward. This hack is roughly the same like when working with the requests.

There is a built in constraint in WCF that you can only work with basically Json or XML. Or raw. That’s what all this fuzz is about. Too bad they didn’t make it obvious or easy to implement. The short explanation is however that if you request/return a Stream, it forces the WCF framework to abandon all it’s nifty things and smart moves and leaves it up to you to decide. So, set the return type to Stream, do your thing, serialization and what not. And send it out. The response will not get wrapped within the return type.

public Stream Check(Stream request){
  var json = ReadStreamAndDeserialize(request);
  //do stuff
  var jsonResponse = Serialize(response);
  WebOperationContext.Current.OutgoingResponse.ContentType = "application/json; charset=utf-8";
  return new MemoryStream(Encoding.UTF8.GetBytes(jsonResponse));

Why do this?

In our case we needed to serialize different types a bit differently and couldn’t get the internal serializer to work quite as we wanted. But also imagine that you could serve images back. You can even stream images back. And what if it is a file service? You could serve back whatever contenttype you like, and make it different depending on the file served. It does add some nice features you can work with to extend your options.

What you should also consider is what it does. In this case we make heavily use of the http protocol as opposed to others, which means it limits your options of just serving data over any protocol. It also takes you closer to the protocol you are working with, which can be both a blessing and a curse. If you don’t know what you are doing, you could end up in a lot of trouble and just having to write hack upon hack upon hack.

Check out the complete working example on GitHub.

Read more

Tagged , , ,

How to make a #REST-ish API with #WCF

Where I work we integrate a lot with external partners where they sometimes dictate the conditions. At the same time we have our technology, architecture and environment to deal with and solve it as good we can. This put us in a bit of a position recently when we were tasked with “make a REST API that conformes to this document”. We use WCF. And then there was headache.

But, since WCF is carrier agnostic, this shouldn’t be any problem right?! You can deliver via HTTP, TCP, you name it. It’s just the flick of a switch in some config. Turns out it wasn’t quite that easy. The document stated that the request will be sent as content-type “application/json”, it also stated that it will be a POST request and furthermore that the actual JSON request will be a payload in the BODY of the message. WCF don’t give you access to the body. Since it is by design to be protocol agnostic and not all protocols have a body or they differ from eachother.

This is all very well documented if you enter the correct search terms. Read more on both the problem and solution here, here (this is where most paths lead) and here.

This is mostly for me to remember for the future since I know now that I’ve gone through it I did it once before but forgot all about it until it was right there in front of me.

While it all sounds complicated it really isn’t. It’s as easy as 1-2-3, like David points out in his blog post on the subject.

1. Add a new WebContentTypeMapper, like so:

public class RawContentTypeMapper : WebContentTypeMapper
  public override WebContentFormat GetMessageFormatForContentType(string contentType)
    //Make if-else statements here if you want to respond differently to different contentTypes. This one will always return Raw regardless of what you attack it with.
    return WebContentFormat.Raw;

2. Make your new content type mapper available for use:

    <binding name="RawMapper">
      <webMessageEncoding webContentTypeMapperType="Your.Namespace.RawContentTypeMapper, Your.Assembly, Version=, Culture=neutral, PublicKeyToken=null" />

3. Put the new available content type mapper to use:

<endpoint contract="MyContract" behaviorConfiguration="MyEndpointBehavior" binding="customBinding" bindingConfiguration="RawMapper" />

(4.) When working with a Raw content type, your usual way of working with WCF will be put slightly out of order. Instead of using your standard contracts, your method will need to take in a Stream. After that you are free to work as you like. Here is what we did.

public string Check(Stream request)
  var json = new StreamReader(request, Encoding.UTF8).ReadToEnd();
  var internalRequest = JsonConvert.DeserializeObject(json);
  var querystring = HttpContext.Current.Request.QueryString; //perhaps some additional data in here?

  //Do stuff

  return string.Empty;

The above will give you everything you wanted from the start. Almost.

Now you are thinking “NICE! And then I just use the UrlTemplate(…) to get a descent way of finding the methods!”. Well, not quite. It won’t turn out like http://mydomain.ext/api/check, but rather http://mydomain.ext/path/endpoint.svt/api/check. While I haven’t tried, I’d go with some URL rewriting in IIS or something. Perhaps you have a loadbalancer who can do it for you, or some other mechanism.

Tagged , , , ,