After some playing around with WCF and Flickr, I decided to move everything internally for the twitter library to use WCF with it's ServiceContract. It was more of a pain that initially thought it would be. WCF is amazingly customizable but still has a couple of downfalls thanks to REST and people not writing their API for all technologies.
The biggest issue is that Twitter throws an Http 403 unknown exception when you call a page and something is incorrect in the url. Well with WCF, it throws a System.ServiceModel.Security.MessageSecurityException, due to the url returning a status code other than 200, and it wraps the inner exceptions inside of that.
I'm sure there is a better way to get around this, but each proxy call is now wrapped by a try/catch in the client class methods in order to check for the MessageSecurityException, then it checks the inner exception and determines if twitter sent back a response error message. If it does the library now throws a twitter exception with error information, otherwise you would only see the WCF exception that would mask the real issue.
Also I renamed the "Service" classes to "Client" seeing that is the proper term for them. The tests are now updated as well to reflect the changes. The tests are a good way of seeing of how to use the library. Last but not least, methods now return arrays instead of lists in order to be more REST friendly.
using Amplify.Twitter;
using System.Security;
// ... stuff
public void Test()
{
try {
string temp = "password";
Twitter.SetCredentials("Username", temp);
StatusClient client = Twitter.CreateStatusClient();
// or StatusClient client = new StatusClient("Username", temp);
Status[] tweets = service.GetUserTimeline();
} catch (TwitterException ex) {
Log.Write(ex.ToString()); // write the twitter rest error.
}
} Labels: Amplify, BHAG, C#, Code, CSharp, JSON, REST, Twitter, WCF
Even though there are quite a few opensource .Net libraries REST API out there, and a really impressive one for Flickr, they tend to never evolve or fork to use the newer framework technologies. I think its great that they support 1.0, 2.0, and mono, but why not fork and support WCF? I think part of the problem that .Net 3.5 use is not wide spread as it should be is not only information overload and bad naming for extension libraries, but also lack of opensource support to provide libraries and basis for current technology.
Flickr tends to be a little more tricky to use when calling it than some other REST APIs. WCF is a cool technology, but needs to be massaged when using it with Flickr due to a couple of gotchas and not so obvious things about WCF. In order to use Flickr, you need to register for an api_key and a shared secret code which is used to create an MD5 hash. You also need to create that MD5 each time you call a method, using the url parameters in a certain way.
There are also a few not so obvious factors about using the JSON part of Flickr. All of the .Net libraries I've seen so far, use XML. While C# is king of parsing XML, JSON tends to be more compact, which means less expense over the wire, though it might mean more time parsing once on the developers end point. So there are tradeoffs to using it.
When I created the classes needed to use WCF to call Flickr, I have the actual "DataContract" object (DTO, Data Transfer Object), A Hash (Dictionary<string, object>) for adding the parameters to create the MD5 signature, A base class for creating the WCF proxy, a custom "WebContentTypeMapper", The "ServiceContract" interface, the actual "Client class", and a mixins class for creating the MD5.
Here are some of the gotchas that I ran into while getting WCF to work with Flickr.
- Flickr makes you create a md5 hash to send with every call for ALL parameters in alphabetical order using your "Shared Secret" Code as part of the md5.
- Flickr's Json response "Content-Type" header is sent not as "application/json" but as "text/plain" which equates to "Raw" in WCF lingo.
- The response object is wrapped and not obvious when it comes to json how the DataContract object should be formed.
- Flickr will wrap the json response in a javascript function unless you pass in the parameter "nojsoncallback=1"
To get around number one, I created an extension method that takes a Hash (Dictionary<string, object>) and adds method that converts the parameters into a MD5 string.
namespace Amplify.Linq
{
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
#if STANDALONE
public class Hash : Dictionary<string, object>
{
}
#endif
}
// different file
namespace Amplify.Linq
{
using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Cryptography;
using System.Text;
using Amplify.Linq;
public static class Mixins
{
public static string ToMD5(this Hash obj, string secret)
{
var query = from item in obj
orderby item.Key ascending
select item.Key + item.Value.ToString();
StringBuilder builder = new StringBuilder(secret, 2048);
foreach (string item in query)
builder.Append(item);
MD5CryptoServiceProvider crypto = new MD5CryptoServiceProvider();
byte[] bytes = Encoding.UTF8.GetBytes(builder.ToString());
byte[] hashedBytes = crypto.ComputeHash(bytes, 0, bytes.Length);
return BitConverter.ToString(hashedBytes).Replace("-", "").ToLower();
}
}
}
Well Gotcha number two, took a bit of research to figure it out. The error I got was that it was looking for Json or XML but could not do anything with "Raw". So the solution is to create a custom binding with a custom WebContentTypeManager.
namespace Amplify.Flickr
{
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Runtime.Serialization;
using System.ServiceModel.Web;
public class JsonContentMapper : WebContentTypeMapper
{
public override WebContentFormat GetMessageFormatForContentType(string contentType)
{
return WebContentFormat.Json;
}
}
}
// different file
namespace Amplify.Flickr
{
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.ServiceModel.Web;
using Amplify.Linq;
public class FlickrClient<T>
{
protected string Secret { get; set; }
protected string Key { get; set; }
protected string Token { get; set; }
protected string Url { get; set; }
protected T Proxy { get; set; }
public FlickrClient(string key, string secret)
{
this.Key = key;
this.Secret = secret;
this.Url = "http://api.flickr.com/services/rest";
this.Proxy = this.InitializeProxy();
}
public FlickrClient(string key, string secret, string token)
:this(key, secret)
{
this.Token = token;
}
protected virtual T InitializeProxy()
{
// using custom wrapper
CustomBinding binding = new CustomBinding(new WebHttpBinding());
WebMessageEncodingBindingElement property = binding.Elements.Find<WebMessageEncodingBindingElement>();
property.ContentTypeMapper = new JsonContentMapper();
ChannelFactory<T> channel = new ChannelFactory<T>(
binding, this.Url);
channel.Endpoint.Behaviors.Add( new WebHttpBehavior());
return channel.CreateChannel();
}
}
}
The 3rd issue, to know that all objects are wrapped in a "Response" object. To create a DataContract for the getFrob method on flickr, it took looking at the json to see what it was returning. The object below is the basic form of the Json object that is returned, it also includes the properties in case an error object is returned.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.Serialization;
[DataContract]
public class FrobResponse
{
[DataMember(Name = "frob")]
public JsonObject Frob { get; set; }
[DataContract(Name = "frob")]
public class JsonObject
{
[DataMember(Name = "_content")]
public string Content { get; set; }
}
[DataMember(Name = "stat")]
public string Status { get; set; }
[DataMember(Name = "code")]
public int Code { get; set; }
[DataMember(Name = "message")]
public string Message { get; set; }
}
// different file
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using System.ServiceModel.Web;
[ServiceContract]
public interface IAuthClient
{
[OperationContract,
WebInvoke(
UriTemplate = "/?method=flickr.auth.getFrob&format=json&nojsoncallback=1&api_key={key}&api_sig={signature}",
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Bare)]
FrobResponse GetFrob(string signature, string key);
[OperationContract,
WebInvoke(
UriTemplate = "/?method=flickr.auth.getToken&format=json&nojsoncallback=1&api_key={key}&frob={frob}&api_sig={signature}",
ResponseFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.WrappedResponse)]
Auth GetToken(string signature, string key, string frob);
}
// the actual client class.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Amplify.Linq;
public class AuthClient : FlickrClient<IAuthClient>
{
public AuthClient(string key, string secret)
:base(key, secret)
{ }
public AuthClient(string key, string secret, string token)
:base(key, secret, token)
{ }
public string GetFrob()
{
string md5 = new Hash() {
{"api_key", this.Key},
{"format", "json"},
{"method", "flickr.auth.getFrob"},
{"nojsoncallback", 1}
}.ToMD5(this.Secret);
FrobResponse response = this.Proxy.GetFrob(md5, this.Key);
if (response.Code > 0)
throw new Exception(response.Message);
return response.Frob.Content;
}
} Labels: Amplify, C#, Code, CSharp, Flickr, JSON, REST, WCF
http://code.google.com/p/twittern
I put together a C# twitter library that uses WCF's DataContract & DataMembers and .Net 3.5's DataContractJsonSerializer. Its currently in alpha stage, as I need to finish writing the tests, documentation and make a simple WPF client for twitter. I needed a twitter library for a personal "secret" project of mine and found that most twitter libraries do not keep up with the twitter API and break when using them. Plus they tend to go to great lengths when parsing the xml. Unfortunately I do not know if this will work on mono yet. It seems that they have "Olive", which is mono's version of WCF and I've seen where they have a path for the "DataContractJsonSerializer". If there are any one familiar enough with mono, please by all means use the code, join the project.
One design decision that I made was to use Json rather than xml as its more compact and less data to transfer. I used WCF because with DataContract & DataMembers you can parse Json and you can name your properties the property way with Pascal Case properties and then tell wcf what attributes of json they represent. This way you don't have properties that look like ruby like "screen_name" or "profile_sidebar_border_color" in your Data Transfer Object in order to deserialize the Json response from twitter.
A basic sample of how to use the library is below.
using Amplify.Twitter;
using System.Security;
// ... stuff
public void Test()
{
SecureString password = new SecureString();
string temp = "password";
for (var i = 0; i < temp.Length; i++)
password.AppendChar(temp[i]);
password.MakeReadOnly();
Twitter.SetCredentials("Username", password);
StatusService service = Twitter.CreateStatusService();
// or StatusService service = new StatusService("Username", password);
List<Status> tweets = service.GetUserTimeline("MichaelHerndon");
}
Labels: Amplify, C#, CSharp, DataContractJsonSerializer, JSON, REST, Twitter, WCF
