8

I'm building a simple RESTful API for a web-based application I'm working on, and I'm wondering about the best way to go about exposing my domain models.

Let's say I have a User class and I want to provide a JSON response with the various user properties. I obviously don't want to publicly expose every property of my model (things such as DateCreated, PasswordHash etc) due to security and bandwidth issues.

I've read into Data Transfer Objects and I'm wondering if this is the way to go. If I'm right I could pass, for example, a User model to my User DTO and ensure said DTO only allows exposure of the User properties I choose (which would also help decouple my models from my public API).

Is this solution appropriate or are there better ways to go about this?

Thanks.

  • 1
    "I'm building a simple public API" and "I obviously don't want to publicly expose every property" do not make sense for me, could you please clarify what you mean? – Uooo Sep 24 '13 at 11:51
  • I've edited my question to provide some more clarity, but essentially what I mean is, my User object has some properties such as Password and DateCreated that should not be shown in the JSON representation of the User, but most of the other user data should be available. I'm wondering if DTOs can help me separate the available properties from the unavailable ones. – James Sep 24 '13 at 12:35
6

That's exactly one of the reasons why DTOs exists.

The tradeoff here is that adding DTOs makes your implementation a bit more complex, and thus prone to errors - such as a mismatch in mapping the domain object to a DTO. Use unit tests for this!

Another thing that you could do with your DTO and tends to be highly overlooked in RESTful services is treating hypertext data for references, nested objects and possible operations.

Refer to Martin Fowler's PoEAA: "[...] it's worth mentioning that another advantage is to encapsulate the serialization mechanism for transferring data over the wire. By encapsulating the serialization like this, the DTOs keep this logic out of the rest of the code and also provide a clear point to change serialization should you wish."

http://martinfowler.com/eaaCatalog/dataTransferObject.html

TL;DR: I like the idea of separating the concerns of domain logic and "RESTful wiring" through DTOS, albeit introducing a more complex design.

  • 1
    I thought as much but just wanted to clear that up! For my situation at least, I think the benefits outweigh the cons. Thanks for your answer! – James Sep 25 '13 at 11:53
  • assuming your back end code is strongly typed, the complexity incurred is out weighed by the compile time type checking. dto.setProp(entity.getProp) mappings will start to fail compiling. – Jason Nov 6 '14 at 18:17
3

Though it is not the primary intent of Data Transfer Objects, DTOs can be used to satisfy this concern in a similar manner to the data portion of a Presentation Model.

As it has been pointed out, this may bloat your design and something as simple as an added field may require changes to bubble up through the additional layers. Because of this, it is advisable to see if you can provide metadata to describe the serialization of the object. In many languages, this takes the form of specialized annotations that can be applied to your domain objects to avoid the tedious translation to DTOs. Packages like Jackson (through the use of Mixins) often take this idea a bit farther to completely separate your metadata from your domain model.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.