Gift Guide

Effective REST Services via .NET: For .NET Framework 3.5


Build Web Services Better and Faster with RESTful Techniques and .NET Technologies

Developers are rapidly discovering the power of REST to simplify the development of even the most sophisticated Web services—and today’s .NET platform is packed with tools for effective REST development. Now, for the first time, there’s a complete, practical guide to building REST-based services with .NET development technologies.

Long-time .NET and Web services ...

See more details below
Other sellers (Paperback)
  • All (3) from $11.99   
  • New (2) from $28.79   
  • Used (1) from $11.99   
Sending request ...


Build Web Services Better and Faster with RESTful Techniques and .NET Technologies

Developers are rapidly discovering the power of REST to simplify the development of even the most sophisticated Web services—and today’s .NET platform is packed with tools for effective REST development. Now, for the first time, there’s a complete, practical guide to building REST-based services with .NET development technologies.

Long-time .NET and Web services developers and authors Kenn Scribner and Scott Seely explain why REST fits so smoothly into the Internet ecosystem, why RESTful services are so much easier to build, what it means to be RESTful, and how to identify behaviors that are not RESTful. Next, they review the core Internet standards and .NET technologies used to develop RESTful solutions and show exactly how to apply them on both the client and server side. Using detailed
code examples, Scribner and Seely begin with simple ASP.NET techniques, and then introduce increasingly powerful options—including Windows Communication
Foundation (WCF) and Microsoft’s cloud computing initiative, Azure. Coverage includes

• Accessing RESTful services from desktop applications, using Windows Forms and WPF

• Supporting Web client operations using Silverlight 2.0, JavaScript, and other technologies

• Understanding how IIS 7.0 processes HTTP requests and using that knowledge to build better REST services

• Constructing REST services based on traditional ASP.NET constructs

• Utilizing the ASP.NET MVC Framework to implement RESTful services more effectively

• Taking advantage of WCF 3.5’s powerful REST-specific capabilities

• Creating RESTful data views effortlessly with ADO.NET Data Services

• Leveraging Microsoft’s Azure cloud-computing platform to build innovative new services

• Choosing the right .NET technology for each REST application or service

Read More Show Less

Product Details

  • ISBN-13: 9780321613257
  • Publisher: Addison-Wesley
  • Publication date: 5/7/2009
  • Series: Microsoft .NET Development Series
  • Pages: 444
  • Product dimensions: 6.90 (w) x 9.10 (h) x 1.20 (d)

Meet the Author

Kenn Scribner has been writing cutting-edge, software-based books on Microsoft technologies for more than 10 years. His books include Windows Workflow Foundation Step by Step (Microsoft Press) and Understanding SOAP (SAMS). Kenn is a senior software consultant whose clients have included CBS, Burton, and Microsoft.

Scott Seely, an architect at MySpace, works on the OpenSocial API, one of the world’s most successful REST-based APIs. Before joining MySpace, he was a developer on the Windows Communication Foundation team at Microsoft. His books include Creating and Consuming Web Services in Visual Basic (Addison-Wesley) and SOAP: Cross Platform Web Service Development Using XML (Prentice Hall).

Read More Show Less

Table of Contents

Foreword xix

Preface xxiii

Acknowledgments xxix

Aubout the Authors xxxv

Chapter 1 RESTful Systems: Back to the Future 1

Chapter 2 The HyperText Transfer Protocol and the Universal Resource Identifier 39

Chapter 3 Desktop Client Operations 87

Chapter 4 Web Client Operations 125

Chapter 5 IIS and ASP.NET Internals and Instrumentation 165

Chapter 6 Building REST Services using IIS and ASP.NET 205

Chapter 7 Building REST Services using ASP.NET MVC Framework 245

Chapter 8 Building REST Services using WCF 281

Chapter 9 Building REST Services using Azure and .NET Services 339

Appendix A .NET REST Architectural Considerations and Decisions 381

Appendix B HTTP Response Codes 389

Appendix C REST Best Practices 407

Index 413

Read More Show Less


Preface for Effective REST Services via Preface for Effective REST Services via .NET: For .NET Framework 3.5 Kenn’s Thoughts: The Road to REST, an Engineer’s Tale

It was the spring of 2008, and I had just completed some work for Justin Smith, a senior engineer and connected systems expert at Microsoft. The work involved developing two related Web sites that would consume services offered by a third Web application that would be hosted in something known as the “cloud.” After six weeks of iterative development, we had a set of Web applications that were designed to demonstrate nearly all the ways Web applications can communicate using .NET technologies.

I’d heard about REST, of course, having been fortunate enough to work with Dino Esposito on several of his ASP.NET and AJAX books. Dino is a huge REST proponent. But I admit my background was more along the lines of the SOAP protocol, and I looked at Web services more as remote method calls than creatures of the Internet ecosystem. It didn’t bother me that I needed fancy proxies to communicate with XML-based (and not JSON-based) Web services. I truly hadn’t consciously considered the notion that remote procedure call (RPC) style messaging wasn’t quite architecturally in harmony with the Internet itself.

But I’d had this nagging concern for some time. SOAP and XML-RPC services were becoming very complex, and it seemed that at every turn we were trying to solve some problem that the basic architecture of the Internet presented. Security, streaming large binary objects, browser-based proxies (for AJAX), and so forth were leading to an ever-increasingnumber of new specifications, each designed to layer more complexity on to what had started as a simple concept. And in most cases, we were trying to bypass the basic workings of the Internet rather than using them to our advantage.

After working with Justin, and after building a very detailed and fully functional set of Web applications that were primarily based on RESTful principles, I found I had drunk from the RESTful Kool-Aid pitcher, and I was stunned by what I had overlooked all of these years. I can remember the epiphany...I literally sat up in my chair, stunned by what I had realized.

What I had overlooked was the simplicity and elegance of the Web’s architecture and design. I had been overcome by the glamour of XML and serializing binary information for transmission in response to requests for actions. I had lost sight of the Internet’s most basic capability of asking for and receiving a resource’s representation. The simplicity and elegance of the Internet struck a new chord with me that day. Even though I had been working with Internet-based technologies for nearly ten years, I found I’d suddenly rediscovered programming for the Internet.

And the simple truth is this is not a bad thing, nor is it uncommon. REST as an architectural concept is precisely in line with the architecture of the Web itself. Any tool you have that can build Web applications can be used to build RESTful services. If you have access to the HTTP method—GET, POST, and so forth—and if you have access to the HTTP headers and entity body, you have all you need to create a RESTful service. Anything else is there only to make creating RESTful services easier by hiding some of the detail. I haven’t had the pleasure of meeting Dr. Roy Fielding, but based on his doctoral dissertation that introduces us all to the concept of REST, I’d hazard a guess that he’d prefer you understand REST at its lowest level before using frameworks that mask the underpinnings. When you do, REST makes perfect sense and things become very clear. Or at least I felt so. Scott’s Thoughts: REST Is Best

From 2000 until the middle of 2006, I worked at Microsoft on Web services. For four of those years, I worked on Windows Communication Foundation (WCF)—that amazing, transport-agnostic, messaging-unification machine. When WCF finally came out, it supported WS-* and some very basic REST/POX messaging. A few folks on the team were hard at work adding first-class REST support in the form of URI templates and extra functionality for HTTP-hosted services that were later released in .NET 3.5. Why this focus on REST? REST was starting to get very popular, thanks to Roy Fielding’s dissertation. Like many in the Web service community, I read his dissertation many times, trying to really understand what made the Web scale as well as it did. When the WCF 3.5 bits started coming out as previews, I checked out the greatly improved REST support. I was getting excited by what I was seeing and learning. In the broader community and at work, I was finding that people were getting more and more comfortable using HTTP as a communication medium to create, retrieve, update, and delete resources.

I also started seeing the value in easy-to-type URLs. Furthermore, I found that the architecture and code just makes sense to developers. During 2006, I taught several multiday classes on WCF and gave presentations on WCF at a few conferences across the country. My talks on REST were well received. My talks on WCF internals weren’t. People appreciated the elegance of what WCF can do. They just did not see the value in the steep learning curve one had to traverse to master the technology. The thing that pushed me over to REST was the realization of why people were flocking to REST over WS-*. In general, developers used Web browsers and built Web applications long before they ever had to add a service of any kind. REST development builds on what Web developers already know, so there is less to learn. WS-* might be elegant and cover many scenarios, but it does not build on what most developers in most shops across the globe already know.

In the summer of 2008, I joined the development team at MySpace as an architect. Guess what architectural style one of the world’s largest .NET sites uses to handle access to Friends, photo albums, and other resources. Yes, it’s REST. The platform is, first and foremost, a Web platform. REST holds more value for HTTP base endpoints than a WS-* one ever will. REST integrates well with so many other platforms without a whole lot of effort. It doesn’t impose structure on the payload contents—only on the payload metadata. REST is a model that novice developers understand and that expert-level developers can easily manipulate. I love the fact that it is penetrating so much of service development. My day job involves working on OpenSocial—already one of the most successful REST APIs ever developed. Through my work with OpenSocial, I have seen that HTTP and REST compose well with many different security mechanisms. I find it interesting that WS-* protocols compose well with other XML mechanisms. REST composes with other HTTP mechanisms. After spending so many years working with SOAP and other RPC mechanisms, I like what REST has to offer. How This Book Approaches REST

Today, we use this stuff. We build solutions based on this stuff. We like this stuff. And we’re truly glad to have this book in our hands as architects and developers. Both authors and the entire team behind this book hope you will find it informative and useful as well.

One thing we didn’t want was a 1,000-page monster. When you understand REST, the concept is actually simple, and applying .NET technologies to create RESTful solutions becomes a relatively easy task. If it can’t be explained in a few pages, something’s not right.

The first couple of chapters introduce you to the concepts involved with REST. In a sense, you’re taken back to the earliest days of the Internet to rediscover how the Internet works and how the architectural concept known as REST fits into the Internet ecosystem so well. The first chapter, “RESTful Systems: Back to the Future,” addresses REST itself, and you learn what it means to be RESTful and how to identify behaviors that are not RESTful. Chapter 2, “The HyperText Transfer Protocol and the Universal Resource Identifier,” is devoted to HTTP and the URI. These are the two fundamental tools you’ll work with when developing .NET-based solutions.

Chapters 3 and 4 dig into the client side of the equation. RESTful services are there to serve a client’s needs, and there is no better way to begin to use REST than to consume RESTful services from a client’s perspective. There you learn what works and what doesn’t, with the lessons you learn translating to design principles when you create RESTful services yourself. Chapter 3, “Desktop Client Operations,” shows you how to access RESTful services from desktop applications (both authors believe that the desktop is not a dead platform but is instead enhanced by Internet data and service access), and Chapter 4, “Web Client Operations,” shows you how to access RESTful services from Web-based applications, including Silverlight 2.0. For consistency, both chapters access a single REST service. Later chapters build individual services unique to each chapter to increase the breadth of exposure to different RESTful service implementations.

After you have a feel for how a client might use your service, it’s time to dive into server-side programming. Here the book starts with the basics: what Internet Information Services (IIS) is, how it is put together, and how you use it to implement RESTful services. Chapter 5, “IIS and ASP.NET Internals and Instrumentation,” leads you through the most foundational server-side technology: Microsoft’s premier Web server. Clearly this is one technology that supports nearly all the other .NET Web-based technologies, RESTful or otherwise, and understanding how it works is crucial to building effective REST services.

Chapters 6 though 8 then use higher-order .NET technologies to implement RESTful services. Chapter 6, “Building REST Services Using IIS and ASP.NET,” uses what you learned in Chapter 5 to create a Web blog service using only traditional ASP.NET constructs. Chapter 7, “Building REST Services Using ASP.NET MVC Framework,” introduces you to the ASP.NET MVC framework and shows how implementing a RESTful service might differ from traditional ASP.NET when you have the MVC framework to rely on. Of course, no .NET book discussing RESTful technologies would be complete without digging into the nuts and bolts of WCF, and Chapter 8, “Building REST Services Using WCF,” does just that.

The final chapter, Chapter 9, “Building REST Services Using Azure and.NET Services,” shows how you would combine cloud computing with RESTful services to accomplish tasks that otherwise would be nearly impossible. In this case the sample application demonstrates a comment service you can execute from behind your firewall on your private network. Your service will reach out and allow other people over the Internet who are working behind their firewalls to work with your service.

We then provide three appendixes we hope you’ll find helpful. The first, Appendix A, “.NET REST Architectural Considerations and Decisions,” discusses some of the architectural aspects and why you might choose a particular .NET technology over another. Appendix B, “HTTP Response Codes,” discusses each of the possible HTTP response codes and in particular what they mean to RESTful services and clients. And, finally, Appendix C, “REST Best Practices,” tries to provide some concise guidance for creating RESTful services.

Let’s face it. When it comes to writing effective software, the more you know, the more effective your software will be. Although we don’t assume that you’re the world’s foremost expert on writing ASP.NET applications, we do believe you’ll have some real-world .NET experience before reading this book. We’re going to be working at some of the lowest levels of HTTP, IIS, and even ASP.NET, so some familiarity with each of these is a plus. But neither is this book a 1,000-page monster, so if there are bits and pieces you’re not so familiar with, there should be plenty here to introduce you to concepts and techniques you’ll find useful in your daily work.

Finally, we’ve set up a Web page in addition to the publisher’s page where you can send comments and questions directly to us. If anyone (gasp!) our sample software, we’ll post updated code there for you to download. Interesting and informative tidbits might find their way there as well, time permitting. Both authors earn their living writing software just as you do, and we’re every bit as busy as you are making ends meet with the world economy the way it has been in the latter part of 2008. But both authors love this architectural concept and are committed to helping you understand and use it as well. So if interesting and informative things come up, we’ll put them on the book’s Web page:

© Copyright Pearson Education. All rights reserved.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)