Category Archives: C# - Page 2

Github C# API: Handling the response with RestSharp

Once we make a request to Github.com with RestSharp, we get a response, and RestSharp gives us a RestResponse object, with which we can do something with the content. The content will be in the format that we specified when we made the request, either JSON, XML or YAML.

Oh crap, complicated string parsing…

RestSharp to the rescue! We don’t have to worry about parsing the response content, because RestSharp can do it for us.

What we need to do, is model the response content into a POCO (Plain Old Clr Object):

public class User
{
	public virtual int Id { get; set; }
	public virtual string Login { get; set; }
	public virtual string Name { get; set;}

	...
}

Note that in this User class, I’ve made the properties virtual, this is not necessary for RestSharp to function correctly, it’s more habit on my part from working with NHibernate; however it does mean you can reuse the same models with NHibernate (if you wanted to do something like store the response in a database, for example).

Then we need to modify our client such that when we execute the request, we instruct RestSharp to construct an instance of the User object. Create the client in the usual way and also create the request in the usual way. The magic is in how the client executes the request:

var request = new RestRequest
				  {
					  Resource = string.Format("/user/show/{0}", username),
					  RootElement = "user"
				  };

var response = client.Execute<User>(request);

var user = response.Data;

As you can see, the Execute method has a generic overload. Internally, RestSharp detects that because we have used this overload, we want to deserialise the response content into an object of the given type, and it performs the deserialisation and constructs an instance of the object. The way that it does this is by looking at the Content-Type header in the response, and it uses the correct deserialiser depending upon the Content-Type. You can see more detail about this on RestSharp’s Github project pages.

It is really easy to work with the response from your REST request with RestSharp, you can access the raw string content of the response, or deserialise it into a POCO – it’s up to you.

Let’s write an API library for Github

Let’s write a C# API library for github.com.

Github has a REST base API, the details of which are available at develop.github.com. Before continuing, I should point out that there is an existing C# library already available, if you want to use that.

We’ll leverage John Sheehan’s excellent RestSharp library to do most of the heavy lifting.

Before we can really do anything, the first task at hand is to learn how to work with RestSharp, and how we can make a request and receive a response. Fortunately, RestSharp makes it really easy, and there are excellent resources on the project’s wiki page which explain how to do things. Let’s see a quick example:

[Test]
public void MakeBasicRequestToTwitterWithRestSharp()
{
	var client = new RestClient("http://api.twitter.com");
	client.UserAgent = "TemporalCohesion.TwitterApi";

	var request = new RestRequest();
	request.Resource = "statuses/public_timeline.json";

	var response = client.Execute(request);

	if (response.StatusCode == HttpStatusCode.OK)
	{
		String content = response.Content;

		Assert.That(content, Is.Not.Null);
	}
	else
	{
		Assert.Fail(response.StatusDescription);
	}
}

Here we are making an authenticated request to Twitter, asking for the public timeline in JSON format, but, the same code can easily be applied to github.com. We’ll see more of that later. First we create the client object, and then create the request object – telling it what resource to actually request, and then we execute the request using the client, and then do something with the response. Pretty straightforward, huh?

There is quite a lot that we can do with the Github API at this point, although you’ll quickly see that to do anything really interesting (i.e. modifying your github account, or creating/forking repo’s) requires you to be authenticated. Fortunately for us, Github uses HTTP Basic Authentication, and, RestSharp has a HttpBasicAuthenticator class, and if you put the two together, you can make an authenticated request to Github like this:

var client = new RestClient
				 {
					 BaseUrl = "https://github.com/api/v2/json",
					 Authenticator = new HttpBasicAuthenticator("test", "test")
				 };

After we set the authenticator, RestSharp takes care of making sure that the headers of the requests we make to Github’s API contain the necessary authentication which identifies us to Github. You’ll note that the BaseUrl here is set to https://github.com/…, so that we can take advantage of SSL. You can can access public data via normal http://, but if we are going to do anything that requires authentication, it will be best if we choose to use https://

Github also provide us with an API key. This is a unique key which identifies us to Github, and give our requests a little bit more security. We can’t set this key with RestSharp, as we need to modify the way the authorization header is generated when we make a request. What we can do though, is to implement our own IAuthenticator to do handle it for us. You can see my implementation up on Github. It’s fairly straightforward – I still wanted to allow basic username:password authentication, as well as username/token: authentication for Github.com. Let’s create a unit test to check everything is working OK.

How do we know if we have made an authenticated request successfully? If you make a request to Github for a user, and you are authenticated as that user, then as well as the standard user response, there is some additional information included in the responses that only you, as the authenticated user, can see. And we can check for this information in the response:

[Test]
public void MakeAuthenticatedRequest()
{
	var restRequest = new RestRequest
            {
                Resource = "/user/show/sgrassie"
            };

	var client = new RestClient
					 {
						 BaseUrl = "http://github.com/api/v2/json",
						 Authenticator = new GitHubAuthenticator(_secretsHandler.Username, _secretsHandler.Password, true)
					 };

	var response = client.Execute(restRequest);

	Assert.That(response.Content, Is.StringContaining("total_private_repo_count"));
}

The unit test is pretty straightforward, I make a request object which will get my user account, I authenticate the request and then execute it. Then I can simply check that the response content contains “total_private_repo_count” – this would only be returned if the request was an authenticated request.

One thing you might notice in the test is that in the GitHubAuthenticator constructor, I get my username and password/api token from the _secretsHandler object, an instance of a class I’ve written which will load my username, password and api key from an XML file. This is so that I don’t have to put my Github.com password and API key into the project’s Github repo, because that would be bad.

Unit Testing Events

Recently I have had to unit test some events in an application I work on. I came up with a workable solution, but I didn’t really like the way it was working, and it just looked ugly. So I did a little digging on Google, and found this helpful question on StackOverflow.

Here is my take it. I’m putting it here so I can find easily find it again. Basically it’s the same, but I’m using a lambda to create my anonymous delegate:

[Test]
public void UnitTestNodeChanged()
{
 var receivedEvents = new List<XmlNodeChangedEventArgs>();
 var document = new XmlDocument();

 document.NodeChanged += ((sender, e) => receivedEvents.Add(e));
 document.Load("C:\file.xml");

 Assert.That(receivedEvents.Count, Is.EqualTo(1));
}

Nice and short, and to the point. We can test the fact that the event was raised (or not); how many times the event was raised; and, we can test the event arguments.

I like it. Some people may not, but it suits my purposes.

Even more on the generic plugin manager

I’ve written previously about writing your own generic plugin manager/framework.

I believe that this is a worthwhile exercise for the beginning programmer, because it firstly teaches you a lot about reflection, and secondly teaches you the advantages that proper use of interfaces can bring to your code. Thirdly it can also teach you to think about how your API might be used by someone else when they write a plugin for your program. In short I think it’s a great exercise.

While writing and using my own plugin framework has been a great learning experience for me, I’ve found that I have outgrown it’s usefulness to me. What made me see this was when I started to think about and begin implementing a way for me to use the framework as a IoC/Dependency Injection tool. This led me off on some Googling and I found Funq, and the the associated screencasts by Cazzulino.

This got me to thinking about DRY. Don’t Repeat Yourself can just as easily mean Don’t Repeat Work Other People Have Already Done (If You Don’t Have To), but DRWOPHADIYDHT doesn’t sound/look nice as an acronym. Perhaps a better way to express that sentiment is “lazyDRY”, or “The re-use of prexisting libraries and code can save you a lot of time, and which effort you can put into your application at a higher level.”

Or in other words, it is foolish to ignore the work that other people have done, unless you have a compelling reason to do so. If you really want to write your own IoC/DI container, then great, knock yourself out. No one is going to stop you.

I’m lazy though. Nanos gigantium humeris insidentes.

Depending on the blogs in your feed reader, or who you follow on Twitter, or just in general googling, you will probably come across references to the same group of IoC/DI containers. Chiefly:

There are others, but it would seem hardly anyone uses them. Of those above, I have so far only used StructureMap and Ninject, and have really liked using both of them. I will try out the others at some point, but so far I’ve liked what I’ve seen in StructureMap and Ninject, I honestly don’t think that any of the others will have anything better to offer me. Besides which, StructureMap has a built in method of using it as a plugin framework. Win.

In Conclusion

What can I draw from all this? I don’t think that I wasted any of my time or effort in writing my own plugin framework. It was a worthwhile exercise which taught me a lot of things, and I urge you to do the same.

More on the generic plugin manager

Update:

I’ve written some more about what I’ve learned whilst working on my plugin manager here: http://temporalcohesion.co.uk/2010/03/17/even-more-on-the-generic-plugin-manager/

A few months ago I wrote about writing a generic plugin loader/manager in C#, where I offered links to several articles and referenced a rather excellent book about C# which I had used to base my plugin loader on. I hadn’t really given it much thought since then, but according to Google Analytic’s, it’s one of the most hit posts on my blog. Recently I had a request to release the source code.

Now when I first wrote that post, I was hesitant to include any code, and I still am – not because I think there is something new and unique with what I’ve done – but, rather that what I have written is not terribly difficult to write. I do not mean to sound snobbish or arrogant at all, I’m just telling you how it is, all I’ve done is to do a bit of reflection on assemblies in a folder, and load instances of certain interfaces.

Anyway…

The scenario is that you want to provide a way for for 3rd parties to be able to add additional functionality to your application at run time. We need to provide a common way for 3rd parties to be able to register their new functionality into our application, in order that the user can take advantage of the exciting new feature being added to the application.

Straight away, you should be thinking to yourself: Interface!

[csharp]

public interface IPlugin
{
/// <summary>
/// Does what ever It is.
/// </summary>
void Do(Action it);
}

[/csharp]

Anyone who now wants to create a plugin for our application must implement our IPlugin interface, as it defines the contract to which our application is bound to, in order to recognise and load plugins. Thus any assembly, that has a class which implements IPlugin is considered by our application to be a plugin which is capable of offering additional functionality.

We can now attempt to load our plugins. We need to have a class which can scan a folder for assemblies, scan those assemblies for types which implement IPlugin, and then create instances of them which our application can use. Loading the assemblies is easy:

[csharp]
public class PluginLoader<T>
{
private IList<T> pluginsList = new List<T>();

}

public virtual IList<T> LoadPlugins()
{
foreach (string file in Directory.GetFiles(this.pluginFolderPath, "*.dll", SearchOption.AllDirectories))
{
Assembly assembly = Assembly.LoadFile(file);
this.LoadObjects(assembly);
}

return this.pluginsList;
}
[/csharp]

We create a generic class, so we can use it with any type of plugin, and not just ones which implement IPlugin, then it’s just simple directory recursion to load all the files in the specified folder which have a file extension of .dll. The real magic happens in the LoadObjects() method.

[csharp]
var types = from t in assembly.GetTypes()
where t.IsClass &&
(t.GetInterface(typeof(T).Name) != null)
select t;

foreach (Type t in types)
{
T plugin = (T)assembly.CreateInstance(t.FullName, true);
this.pluginsList.Add(plugin);
}
[/csharp]

Using LINQ, we extract all the types from the assembly which are classes, which implement the interface which is a typeof(T) – T being the type we specified when we instantiated the class. You could just as easily here specify the type should inherit from some other type, and you could also check to see if a class has some assembly level attribute.

Why would you want to do that? Well, we can use an assembly level attribute to decorate the plugin class with meta-data about the plugin, such as the author, a short description, the name of the plugin, and it’s version.

[csharp]
public virtual KeyValuePair<string, List<KeyValuePair<string, string>>> GetPluginInformation(Type type)
{
var attributeInfo = from pa in type.GetCustomAttributes(false)
where (pa.GetType() == typeof(PluginAttribute))
select pa;

foreach (PluginAttribute p in attributeInfo)
{
data.Add(new KeyValuePair<string, string>("Author", p.Author));
data.Add(new KeyValuePair<string, string>("Description", p.Description));
data.Add(new KeyValuePair<string, string>("Name", p.Name));
name = p.Name;
data.Add(new KeyValuePair<string, string>("Type", p.Type.ToString()));
data.Add(new KeyValuePair<string, string>("Version", p.Version));
}

this.attributeInformation = new KeyValuePair<string, List<KeyValuePair<string, string>>>(name, data);

return this.attributeInformation;
}
[/csharp]

Or you could create a struct to use as a DTO for the plugin meta-data, it’s up to you.

I’ve removed all the comments and exception handling from the code I’ve posted purely just to save space, you’d really want to include that – especially the exception handling. But that’s really all there is to it, you might want to have a property to access the actual plugin list, or return it from a LoadPlugins method, it’s up to you.

You’ll notice I’ve made the methods virtual, you may want to use this class as a base class in another class. For instance I’ve got an additional class which inherits from my plugin loader class which does specific tasks for a particular type of plugin, and another which does different tasks for a different type of plugin.