Service Design Patterns for REST and WS*/SOAP
Web services have been put into practical use for many years. In this time developers and architects have encountered
a number of recurring design challenges related to their usage. We have also learned that certain design approaches work
better than others to solve certain problems.
This site is for software developers and architects who are currently using
web services or are thinking about using them.
It was created as the companion site for a book on Service Design Patterns to be released
Addison Wesley in the near future.
The goal of the book and this site is to acquaint you with some of the most common and fundamental
web service design solutions, and to help you determine when to use them. All of the concepts discussed here are derived
from real-life lessons.
Service developers are confronted with a long list of questions:
- How do you create a service API, what are the common API styles, and when should a particular style be used?
- How can clients and services communicate, and what are the foundations for creating complex conversations in which multiple parties exchange data over extended periods of time?
- What are the options for implementing service logic, and when should a particular approach be used?
- How can clients become less coupled to the underlying systems used by a service?
- How can information about a service be discovered?
- How can generic functions like authentication, validation, caching, and logging be supported on the client or service?
- What changes to a service cause clients to break?
- What are the common ways to version a service?
- How can services be designed to support the continuing evolution of business logic without forcing clients to constantly upgrade?
These are just a few of the questions that service developers must answer. This site provides a quick overview of several design patterns from the book that address these questions. The patterns you will find here may be used to create web services that either leverage SOAP/ WSDL or follow the REST architectural style.