CODEWITHSUNDEEP
javarestjersey
Syb3rian
Syb3rian

Reputation: 171

Jersey. Nice way of hiding some of a POJO's fields in a response for a REST request

Let's assume the following example. The POJO class:

@XmlRootElement 
public class User {
    private String id; 
    private String email;
    private String password;
    private String firstName;
    private String lastName;

   // getters and setters
}

The resource class:

@Path("user")
public class UserResource {
    private UserRepository userRepository = new UserRepositoryStub();

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    @Produces({MediaType.APPLICATION_XML,MediaType.APPLICATION_JSON})
    public User createUser(User user) {            
        return userRepository.create(user);
    }

    @GET
    @Path("{objectId}")
    @Produces({MediaType.APPLICATION_XML,MediaType.APPLICATION_JSON})
    public Response getManagedObject(@PathParam("objectId") String objectId) {
        if (objectId == null) {
            return Response.status(Response.Status.BAD_REQUEST).build();
        }
        User user = userRepository.findUser(objectId);

        if (user == null) {
            return Response.status(Response.Status.NOT_FOUND).build();
        }

        // Possible, but seems that not nice solution
        // user.setPassword(null);            

        return Response.ok().entity(user).build();
    }        
}

In this simple example I want that the GET request {url}/user/12345 doesn't return password field. I've commented one solution I don't like.

In general while working on the API I want to have configurations of visibility of POJO's fields for every request. Is there an elegant way of achieving that?

Upvotes: 0

Views: 998

Answers (3)

MarianP
MarianP

Reputation: 2759

the general practice is to have a service layer in between. you then have a dto object that is an io object for the outside world that is converted to your resource/entity/repository/whatever object. you need to provide conversion/mapper/whatever between those 2 types of objects and you don't set the password when going in dto to resource direction. same thing is usually done for ids in rest interfaces. you don't want anyone to update a resource and by providing an id in the input object to update a different object. this is how things are usually done even though it means extra code, this is usually trivial. can be simplified using a config using Dozer framework or something similar.

from a design point of view resource/persistence layer should only contain atomic operations. what happens if you need to do several of those for a single resource? you'd have to put it in a single method in the resource class. this way you'll be mixing the rest/io logic with what should be in the service layer. easier to make a mistake and harder to write isolated unit tests for

Upvotes: 1

Ori Dar
Ori Dar

Reputation: 19000

Assuming that you want the POST method (un-marshaling) to include the password - but not the GET method (marshaling) - and you are using JAXB, you can write an XmlAdapter.

Its primer use is to convert between mappable and unmappable classes, but it can do the trick here.

public class PasswordAdapter extends XmlAdapter<String, String> {

    @Override
    public String unmarshal(String v) throws Exception {
        return v;
    }

    @Override
    public String marshal(String v) throws Exception {
        return "***";
    }
}

Then specify that adapter for the password property:

class User {

    //...

    @XmlJavaTypeAdapter(PasswordAdapter.class);
    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }
}

Upvotes: 1

user4582986
user4582986

Reputation:

Create a TransferObject i.e TO or DTO which holds the fields that you want the user to show in JSON response. You can use @JsonIgnore on the field and the JSON parser wont parse that field and thus wont be included in response.

Upvotes: 2

Related Questions