How to web enable .NET libraries

I think that if your library was not designed to be exposed to the Internet, then doing so is a bad idea.

Further, if your library doesn't deal with things that make sense as resources in an HTTP sense, then it's not a good idea to expose them with a REST interface.

In response to the comment, "Why?"

I'll assume it's a well-designed library. I assume you had certain requirements in mind when the library was designed; certain use cases and scenarios; you may even have written samples of using the library, just to make sure that it was easy to use. As a result, the library met all of these requirements, and can be called well-designed.

But you don't seem to have included "expose to the Internet" in your requirements, or use cases. You don't seem to have included "expose via a REST interface", either. Chances are that the library that is well-designed to meet one set of requirements will not be well-designed to meet the other two, unless it's by accident.

This is especially the case for the REST aspect. The objects exposed by a library are quite unlikely to meet the HTTP definition of "resource" that REST is based on. Attempting to twist them into the right shape will just be painful.

My recommendation would be to get a new set of requirements together for exposing the functionality of your library as a well-designed set of services. These services would be implemented by calls to your library.

In an ideal world, this process would result in a REST API that is exactly like the one you would have designed in the first place. But it may result in something quite different.

If I could upvote this multiple times I would.

Darrel Miller 2009-07-15 17:27:02

Darrel, John, why? It seems like with a well designed library, GENERALLY you should be shooting for simple/secure outputs anyway, not exposing insecure innards of the code, checking your inputs thoroughly to avoid security risks. This seems like a good fit for REST. Of course, an interface designed for REST from the ground up would obviously be optimal, but I am trying to assume here that we are trying to build reasonably responsibly behaving libraries in the first place.

Kevin Radcliffe 2009-07-15 17:48:23

John, thanks for the elaboration, this helps quite a bit, the first answer to my question seemed a bit like "You don't!". It does seem intuitive or almost implicit that you would want to shape/craft an interface appropriate to REST (vs. trying to shoehorn a 1 to 1 method correspondance into REST). Just like you would for any interface you're crafting.I'm still curious though, once you've thought carefully about that interface, how are you exposing it? I didn't intend for the question to be technology agnostic, because the simplicity/elegance of the solutions does matter to me.

Kevin Radcliffe 2009-07-15 18:47:12

I would use WCF for its flexibility. The interface could be exposed as REST, or SOAP, or using TCP/IP or message queues, with little or no change in code. There's no better way to do it in .NET.

John Saunders 2009-07-15 18:56:06

Uh, yes, there are plenty of better ways to do it in .net. OpenRasta rocks for http, the transport independence promise has failed so many times it's not even funny anymore.

serialseb 2009-08-28 16:58:28

ansaurus

tags:

views:

answers:

How to web enable .NET libraries

related questions