Service APIs Client-Service Interactions Request and Response Management Service Implementation Service Infrastructures Service Evolution API Patterns

Data Transfer Object

A web service uses JSON or XML structures in requests or responses.
How can one simplify manipulation of request and response data, enable domain layer entities, requests, and responses to vary independently, and insulate services from wire-level message formats?
Data is often extracted and copied from XML or JSON request structures to meaningful domain objects because these objects tend to be much easier to work with. However, developers must write a fair amount of code to accomplish this task. In an attempt to simplify this process, developers often annotate the properties (i.e. getter/setter methods) of Domain Model objects to leverage data-binding technologies like JAXB and .NET's DataContractSerializer. Data binding technologies can be quite productive for service developers because they automatically deserialize request streams, instantiate the required objects, and move request data to these objects. A similar process happens in reverse when responses are returned. Unfortunately, this strategy yields several negative side effects. First, developers must contend with circular references. Even worse, this approach causes the client to become tightly coupled to the internal Domain Model. This means that whenever a domain object changes, the client will probably have to change as well. Likewise, if a client requires a change in a request or response structure, then the Domain Model must be altered. Developers may eliminate this coupling by reverting to the use of structure-specific APIs to parse data. However, if this code is included within the service it may decrease service maintainability, lead to duplicate code, and increase the service's coupling to the wire-level formats used in messages.
Create distinct objects to represent request and response payloads. Consolidate the mapping logic that reads and writes these structures.
Data Transfer Object: Create distinct objects to represent request and response payloads. Consolidate the mapping logic that reads and writes these structures.
Data Transfer Objects (a.k.a. DTOs) are reusable classes that contain related data and no business logic. They may be defined on the service side, client side, or both sides of the communication channel. Their properties (i.e. getters/setters) may wrap primitive data types (e.g. integers, strings, etc.) or other DTOs. Data Transfer Objects were first described as a means to reduce the number of method calls in distributed object systems (e.g. CORBA, DCOM). However, this same pattern can also be used by web services to simplify manipulation of request and response data, and to decouple message structures from domain layer entities. DTOs make it easier for services to manipulate request and response data because the services don't have to use structure-specific APIs (i.e., for JSON, XML, etc.). DTOs also decouple domain layer entities from request and response structures because they are created as separate entities whose sole purpose is to define how data is received and returned from a service. Data may be mapped into and out of DTOs through custom code or with data-binding technologies. With the former approach, the logic to move data to and from DTOs may be centralized in the DTO itself, or within Request Mappers and Response Mappers.