如何使用Jackson和JaxB序列化构建我的RESTful Web服务

Question

I have some sensitive domain objects that I would like to convert to json and xml. I am using spring view resolution to do this, but that is beside the point.

I'd like to add annotations to the domain objects to specify which fields should be converted to xml / json.

Something like

@XmlRootElement
public class SensitiveDomainObject { 

...

    public String getPassword() {...}

    @XmlAttribute
    @JsonValue
    public String getAccountName() {...}

    @XmlAttribute
    @JsonValue
    public String getGoldMemberStatus() {...}

}

I want getAccountName() and getGoldMemberStatus() to be serialised to json and xml, but getPassword to never be serialised.

What I don't want is

1) Separate 'annotation placement strategies' for json and xml as that gets confusing if one needs to markup different methods in different ways as standard.

2) To be explicitly ignoring fields. This is because if some programmer comes along in the future and adds a newly sensitive field without including for example the @JsonIgnore annotation, suddenly that sensitive field is shared.

3) To have to make methods like getPassword() private. I still want to be able to call getPassword() internally.

Has anyone done this or have any thoughts?

EDIT

Included a picture from IBM showing essentially the design I ran with, with explicit DTOs with annotations in the business logic layer. The presentation layer figures out which DTO to request and serve based on the incoming URL.

Answer 1

If you care so much about differentiating what you your business classes are and what is transferred, you may consider implementing a separate package of DTO classes which will explicitly include only those properties you'd like to transfer.

In this case you'll have to explicitly include the transfer properties, this can't happen because the programmer forgot it.

There are other approaches to this like adding some validation rules that the property like password is ignored and enforce them on JAXB context level. But this will only work until someone not knowing will name it kennwort or credentials or whatever may come in mind and your validation rules will be out of effect.

So I see two way: * Either you trust the programmer (and all the QA/QS process like code reviews etc.) to support her/him. * Or you make your transfer classes explicit.

For important external interfaces I'd probably go with the second approach (explicit DTOs). If password ends up there, it can't be by forgetting, it will only be on purpose.