Implementing Join/Leave (part 3): The RESTful Services
This is the last of my posts on this topic and promises to be rather short. The previous post covered the functionality to join or leave and the one before that covered determining group membership via EWS. In this post I will cover the idea that I want to implement access to this functionality via REST based interfaces to facilitate, not only use from a code caller, but also a direct link to the function. To start with, I am using Visual Studio 2010 RC which you may download and install. As such, the project types for RESTful services are part of it. I'm not a guru or even particularly knowledgeable in the proper way to format REST based service endpoints; so, I'm just going to format them based on what I need and what is possible and hope it fits what is generally accepted as copacetic for REST based services. Since I already have created some functions in the previous posts I'm going to refer to them and mostly focus on the signatures for the functions.
To get started, you'll need to create a new project for the services. You can do this be creating a new project or adding a new project to your existing solution. Once you do you'll be prompted for project type and you will want to select Web and then subsequently choose the project type WCF REST Service Application:
Once the project has been created implementing the functionality will be rather simple. Just copy and past your existing functionality into the service1.cs as part of the Service1 class. Also, go ahead and do any modifications to naming that you want; for example, I renamed mine to WcfDirectoryServices. Next comes the important part: adorning the method signatures in order to get them properly exposed via a RESTful interface.
If you used the same signature that I did for group look-up you'd be working with:
public bool IsInGroup(string ParentDG, string UserEmail){...}
Before I adorn the signature to get it exposed I have to decide on how I want this accessed. Should it be a Get or a Post? Do I want to pass the input information as query string info or as part of the URL path? My thoughts for this are:
- I'd like to have it as an easy URL + query string that I can just do an HTTP Get to execute. Thus, making it easy to link and include anywhere in a site, document, and (or) email.
- I would like it to be clearly explicit.
And that is about it for what I have in mind for it. So, my full request might look something like: https://[server/ name]/[Service Object]/[Method]?UserNick=[value]&DGNick=[value]. In my case, on my local machine that will result in a request that looks like the following: https://jofultztoshiba:19983/GroupServices/IsInGroup?UserNick=jofultz&DGNick=Administrators. To get the service exposed in that manner I'll adorn my signature as follows:
[WebGet(UriTemplate = "IsInGroup?UserNick={UserNick}&DGNick={DGNick}")]
public bool IsInGroup(string UserNick, string DGNick){...}
WebGet specifies that it will be an HTTP Get. The UriTemplate describes how the URL + query string should be constructed. If I didn't include IsInGroup in the UriTemplate and left that blank then a call directly to the GroupServices objects would attempt to execut this code. I don't really want that, because I want a call that is descriptive of what I want the service to do. So, I add "IsInGroup" to the UriTemplate thus forcing it to match for that in the request. Since I want explict names I simply type them in and the items in braces "{}" represent the variable names that match the variables in the signature.
That is about it for exposing the IsInGroup test. To do the join leave functionality I would simply rinse and repeat for the signature of the method that I used for the Join/Leave functionality. Again, I chose WebGet, because I want to make it an easy link and not require a post or anything of that nature, but you may choose differently.