CODEWITHSUNDEEP
jsonjaxb
John Deverall
John Deverall

Reputation: 6280

How to architect my RESTful webservice with Jackson and JaxB serialization

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.

enter image description here

Upvotes: 0

Views: 125

Answers (1)

lexicore
lexicore

Reputation: 43661

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.

Upvotes: 1

Related Questions