In the first and second parts of this post, I described what makes a REST service different from a SOAP service and how to use WCF to create one. In this post, we’ll look at what a REST client may look like and add some security around the service.

In most line-of-business services, some sort of security system is usually required to prevent unauthorized access to the service’s data. One of the easiest ways to accomplish this is to use the ASP.NET Membership Provider and its associated services. In our example, I’ll be using the NuGet package called “ErikEJ.SqlCeMembership" to quickly create a database of users; without a full SQL Server instance. Once the NuGet package is installed, build the project and navigate to Project > ASP.NET Configuration to setup your users. Make sure to create at least one group and one user. I’ve called my group “Users” and my user, “user1.”

In the first part of this post, I discussed REST and how it compares to SOAP-based services. In this part, we’ll figure out how to create a REST service with WCF and what it takes to start thinking in a “RESTful” way when designing a REST service.

[more]

REST services are the new “hotness.” All of the cool kids are doing them. I (not that cool of a kid) feel as though I’ve been left behind -- holding onto my SOAP messages like an old curmudgeon holding on to his last dollar. After all, SOAP-based services have served me well; all the way back to the .ASMX days. So, I’m the first to admit that traditional (SOAP-based) web services still have a place. They are extraordinarily easy to use, nowadays, because the tooling around them is so polished. On top of that, I can’t think of a platform that doesn’t support them, today.

[more]

Last night at the Lincoln .NET User’s Group, we had our second laptop meeting. A few people brought some code, a dev tip, or a fully working program to demo. I choose to show my "100 Line Web Server" I created to perform some unit testing on an app that was HTTP-centric, lately.

So, here is the entire program. I hope it’s useful to some and at least interesting to most.

JavaScript Object Notation (JSON) is one of the technologies used by AJAX and other "Web 2.0" technologies. It is a way to communicate in an object-oriented fashion between the web server and a client-side, JavaScript-based application. Every now and again, you might find yourself in a situation where you would need to consume a JSON service, but without a JavaScript endpoint. I ran into this situation when I needed to talk to an application that exposed a web interface, but has no other API hook. My mind first jumped to "screen scraping" the web pages in the exposed web interface. However, when I started to dive into the HTML, I found a very rich JSON service behind those pages.

An example message that I saw coming back from the application looked like this: