I spent Sunday afternoon battling an odd WCF error.
System.InvalidOperationException: Incoming message for operation [your operation here] contains an unrecognized http body format value ‘Xml’. The expected body format value is ‘Raw’. This can be because a WebContentTypeMapper has not been configured on the binding. See the documentation of WebContentTypeMapper for more details.
Troubleshooting this issue sucked. Here’s the deal: WCF helpfully attempts to parse any incoming “text/xml” requests automatically. If you’ve defined the input parameter on a WebInvoke operation to be a Stream, WCF can’t bind to the method and returns an HTTP 400.
There’s two ways to solve this problem: Change the input parameter from Stream to XmlElement, or configure WCF to treat this request as Raw. I picked the former method. Carlos Figueira explains the latter method.
If folks are interested, I can post some more detail about the problem and the resolution. For now, I have to finish making things work.
Edit: So here’s the rest of the story, since Brad asked.
I wasn’t sure exactly what triggered the issue. I got this behavior with just one WebInvoke and one WebGet operation using the same URI template. What I’d done was to create a generic ObjectService that exposed the same RESTian operations for several different types of objects. The particular operation in question looked something like this:
PostListAsXml had accepted a Stream. That seemed to work in other places, but then I started noticing the
I think the right way to solve this problem is to follow Carlos’ advice, and create a new WebContentTypeMapper-derived class. But I didn’t have time to figure out exactly where to plug it in, and I was afraid that I might introduce other problems. I just didn’t know enough about the inner workings of WCF to know whether that was a safe operation.
Since we hadn’t shipped the interface yet, I was free to change the return type from Stream to XmlElement for the one or two WebInvoke operations that were returning errors. Fewer lines of code needed to change, and I knew I wouldn’t break anything else.
Of course, I’m probably just setting myself up for more pain down the road, but sometimes you just need to get things done, y’know?
Anyway, since I’ll likely revisit this decision in a later release, I’d love to hear what other folks did in this situation.
The question was: What is the best / most flexible way to have WCF output XHTML?
Here’s how we do it at Infovark. While I’m not sure that our approach is the best way, it does the job.
Our approach is to use the DataContractSerilizer to generate XML, then apply a Complied XSLT transform and return the result stream, which should now contain XHTML. Here’s a simplified version of our code:
It works for us, but if you’ve got other, better ideas, please let me know!
I know it’s possible to transmit Internet Protocol by carrier pigeon, but I’m not sure I could recommend it to our customers with a straight face. By the same token, I’m continually surprised to hear vendors and consultants insist that Web Services can be done without the web.
Yet I’ve seen that claim repeated all over the Internet. Sure, it’s true in the academic sense. Technically, there’s nothing wrong with “webless” web services, just like IP by avian carrier will eventually get the job done (though latency and packet loss are a challenge). But practically speaking, why would you use anything other than HTTP?
The “webless web services” meme has infected a number of good ideas. The SOAP standard is a case in point. At first, SOAP was a simple XML wrapper around an XML payload. (Remember when the S in SOAP stood for Simple?) Then a variety of industry heavyweights jumped on the bandwagon, and soon SOAP could be used with any protocol.
Nicholas Allen recently shared a great presentation on REST and SOA given by Stefan Tilkov at QCon. Stefan makes some great points about how RESTful web service design aligns well with the goals of Service Oriented Architecture (SOA).
Sure, you could use the WS-* stack if you like, but RESTful web architecture is a proven, scalable and truly simple approach, as long as you don’t mind having to use HTTP.
Much of the added plumbing in the WS-* stack is there to help transition older computer-to-computer network communication technologies. It allows applications that depend on CORBA or DCOM to tunnel through firewalls. But unless you’re trying to retrofit a system built before, say, 1998, you can skip all that stuff.
Wasn’t using web protocol the whole point of web services anyway? As Stefan said in his closing comments: “Protocol independence is a bug, not a feature.”
Use a RESTful architecture for new development. Put the web back in web services.
I’m on record as being skeptical of the semantic web. Or rather, I’m skeptical of much of the marketing hype around the semantic web. That’s not to say that semantic technologies won’t be useful.
I still believe that both Resource Description Framework (RDF) and the Web Ontology Language (OWL) are too complicated to gain widespread adoption. But maybe we don’t need their academic rigor. Microformats offer a way to get some of the benefits of the semantic web using plain ol’ HTML.
Here’s an example of our company address in hCard format.
The address above is marked up in such a way that (some) web browsers can identify it as a street address. But it’s nothing more than ordinary HTML. Here’s what the code looks like:
It’s simple enough that it just might deliver where RDF and OWL fail, becoming part of every web developer’s toolkit.
You can experiment by creating your own hCards using the hCard creator.
I’m staring at a gorgeous visual right now. It’s an image of how the Infovark UI might look. I can imagine myself clicking on that tab, and navigating off to a world of beautifuly laid out, useful information…
I really want to see this go into production. I really do…
But it won’t. Our designer used Photoshop.
There’s nothing wrong with Photoshop, of course. Nor Gimp, nor Paint.Net, nor any other image editing tool you could mention. And there’s nothing wrong with our designer, either. She really knows her stuff. But I can’t help but feel that perhaps you shouldn’t let your designer touch an image editing tool when she’s working on a web design.
When you open an image editing tool, you’re presented with a blank canvas. And the first instinct of any artist or designer is to fill that canvas.
Web pages aren’t canvas. On canvas, or on paper, it’s just as easy to paint one corner as another. This isn’t true of the web. With a web page, one corner is much easier to reach than all the others. In languages written left to right, it’s the upper left hand corner.
Not all sides of the image are equally easy to reach, either. The top and left edges of your canvas are much, much easier to paint than the right or bottom edge.
It’s as if the upper left corner has its own gravity, and draws all other page elements toward it. Like a black hole, it warps your grid.
It is many times harder to place elements in the bottom right corner of a page than the upper left. You’re fighting the pull of gravity the whole way. You’ll have to build on top of block elements like
DIV to get there. And beware of the CSS
float property. As its name suggests, it isn’t supported by anything. It can wreak havoc on your layout, setting off a cascade of unwanted effects.
The web also suffers from typographic poverty. In an image editing tool, your designer will have access to hundreds — perhaps thousands — of fonts. They can be used to create images freely. But all but a handful of these fonts can be used on the web. Most designers know what fonts are actually available for use. You can cheat in certain cases, and use images instead of text for certain headers and buttons, but many of the effects you’d like to achieve with typography are simply not possible today.
Your web canvas won’t take all kinds of paint, either, unlike an ordinary image file. Not all browsers support transparency in images, for example. Placing gradients and shadows can be tricky.
But the biggest challenge can be the dynamic nature of a web page. Looking at a design, it can be hard to imagine the effect a blinking, spinning animated widget will have on your audience. It’s also hard to visualize what rollovers or pop-ups might do to the overall feel of the page.
Unlike paper or canvas, a web page can be stretched and scrolled. What does that do to the positioning of its elements? What happens when a user adjusts the font size in the browser, but embedded gifs and jpgs remain the same size?
But the biggest drawback to having your designer work in Photoshop is that to the layman, the web site looks almost finished. They’re pretty, these Photoshop Sirens, and they sing! They will draw you in…