I’m currently writing a bunch of media type parsers and have been struggling with the question of whether it is wise to take a dependency on Tavis.Link. I do believe that libraries should be as loosely coupled as possible and I really don’t like libraries that have a big web of interdependencies.
However, when I build media types, chances are they are hypermedia types. Therefore they need a definition of a link. Tavis.Link is build based on RFC 5988 which is the best effort we have to date on defining what a hyperlink is. In theory I could define an interface and allow each parser to define their own link implementation, but that just seems like unnecessary complexity.
I’ve decided that I’m going to take the plunge and make all my hypermedia based media type parsers take a dependency on Tavis.Link. This has two side-effects. Tavis.Link is itself dependent on Tavis.UriTemplate. This is tiny DLL that supports filling in URI parameters based on RFC 6570. It’s use is optional and I apologize to anyone who wants to use Tavis.Link but doesn’t want to use URI Template. However, I suspect that to be a very small number of people.
The other dependency which is a bit more significant is the fact that Tavis.Link takes a dependency on System.Net.Http. This means that it cannot be used by .net 3.5, which is not a huge issue for me. The other issue is how useful this library will be in an Owin environment. I may consider splitting Tavis.Link into two libraries, one with the dependencies on System.Net.Http and the other without. For the moment, I’m going to accept the dependency.
Taking dependencies on libraries that comply with RFC specs should in theory be a bit less controversial and it does encourage users of the libraries to comply with specs. Here’s hoping this isn’t a mistake.