3

If a method of a JAX-RS application would return a domain object, the representation (say JSON) would contain all attributes of this object - right? But what if this object would contain "private" data, that shouldn't be exposed to the web?

And what is about the other direction from outside in: how could be prevented that private fields are overridden?

The only solution to this seems to create data transfer objects (dto).

To use an "automapper" wouldn't be the solution unless one can not specify what fields to map.

So, forces JAX-RS the developer to create DTOs? Or is there another solution?

Community
  • 1
  • 1
deamon
  • 89,107
  • 111
  • 320
  • 448

3 Answers3

3

For transparent marshalling and unmarshalling to and from XML of your entity, annotate it with JAXB annotations (a class can be annotated with both JPA and JAXB annotations and, this way, give an XML representation as well as be persisted in a database). 

@Entity
@XmlRootElement
public class MyEntity implements Serializable {

    @Id @GeneratedValue
    private Long id;

    ....

}

In the above example I use only one JAXB annotation @XmlRootElement. Now, let's say that you don't want the id property in the serialized XML. Simply add the JAXB annotation @XmlTransient to it:

@Entity
@XmlRootElement
public class MyEntity implements Serializable {

    @XmlTransient
    @Id @GeneratedValue
    private Long id;

    ....

}

So, no, there is no strict need for DTOs (and the boilerplate code to map them to and from entities).

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • Does @XmlTransient work with every output format JAX-RS supports or is it limited to XML and JSON? – deamon Jan 13 '10 at 17:05
  • @XmlTransient is from JAXB, JAXB is for XML. JSON outputters happen to support a subset. So it depends on serializer used for format in question. FWIW, I don't know of other 'standard' serializers, so it may be a moot point. – StaxMan Feb 08 '10 at 00:27
  • Is this valid for bidirectional relationships between entities as well? I remember running into cyclic reference issues. May be I missed something obvious and started creating dtos. Could you please share your thoughts on this? – opensourcegeek Aug 23 '11 at 18:00
2

I think it is better to say JAX-RS requires you to use representations.

My Foo domain object has no idea that it is being used in a RESTful manner. It only knows of Bar (another aggregate root) and whatever entities it can navigate from via that Bar. In fact, I also have a command-line interface to this application that doesn't use REST or even HTTP.

My RESTful interface wraps Foo/Bar in to representations that link to each other via URIs. I guess you can call these DTOs, but if you (like stated in other answers) just annotate your domain model with what is required to marshal and unmarshal them then I think you're coding yourself in to a corner that prohibits HATEOAS.

This is also apparent when you have a collection. If Foo->*Bar are you going to return all of the Bar items in their unmarshalled form? Why not just a URI and maybe some other minimal data, e.g.

GET foo/fff

<foo>
  <link rel="self" uri="uri="foo/fff" />
  <bar uri="bar/abc123">
    <status="Active" />
  </bar>
  <bar uri="bar/qqq">
    <status="Inactive" />
  </bar>
</foo>

If the client wants to know more about a given Bar, it can

GET bar/abc123

<bar>
  <link rel="self" uri="bar/abc123" />
  <foo uri="foo/fff" />
  <status>Active</status>
  <title>Some Bar</title>
  ...
</bar>
Doug Moscrop
  • 4,479
  • 3
  • 26
  • 46
  • Of course that is just the beginning, because with HATEOAS you're going to provide other links that "mean" something that a client can act on, and that's where it is important to remember that URIs are opaque and don't have to point to a document. For example, for bar/abc123, you might POST it to a bar/deactivate URI and that would set the status to inactive. Or a common deactivate URI - or whatever ! The meaning is in the hypertext and the relationships you define. You're *not* supposed to be just passing DTOs around. – Doug Moscrop Aug 25 '11 at 18:33
  • 1
    The downside is that using these *Representation classes means a whole other set of objects to maintain. I've seen people using the Resource class itself to "be" the representation. Maybe that is the better choice, however it seemed cluttered to me. My only second-guess so far is that I need to push even more logic in to domain services and entities and keep it out of the resource, but I've avoided this because I really don't want the domain to know that its being used in a RESTful way. – Doug Moscrop Aug 25 '11 at 18:33
1

@XmlTransient (or a corresponding annotation) instructs the mappers/marshallers not to include the annotated property in the serialized output.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140