CODEWITHSUNDEEP
javajerseyjax-rs
GhostCat
GhostCat

Reputation: 140427

Jersey/REST: delegating requests to different sub resources without code duplication?

We created a resource, like:

@Path("whatever")
public class WhateverResource {

@POST
public Response createWhatever(CreateBean bean) { ...

@DELETE
@Path("/{uuid}")
public void deleteWhatever(@PathParam("uuid") UUID uuid) { ...

and so on for GET, PUT, HEAD.

Now we figured that we figured that we need to check whether the underlying feature is actually enabled. A single check, and when it fails, all operations should simply result in a 501.

My first thought was be to duplicate the existing resource, like:

@Path("whatever")
public class WhateverResourceIsntAvailable {

@POST
public Response createWhatever(CreateBean bean) { 
  throw 501

@DELETE
@Path("/{uuid}")
public void deleteWhatever(@PathParam("uuid") UUID uuid) { 
  throw 501

So, two resources, both specifying the exact same operations. Leading to the problem that we can't (easily) invoke that check at the point in time when the resource needs to be registered.

Beyond that, this duplication doesn't look very elegant, and I am wondering if there is a "more canonical" way of solving this?

EDIT: another option would be to add the check into the existing resource, into each resource, but that means: doing the check for each operation. Which can easily be forgotten when adding new operations.

I envision something like having:

And ideally, without duplicating checking code, or duplicating operation end point specs.

Upvotes: 2

Views: 274

Answers (1)

GhostCat
GhostCat

Reputation: 140427

Following the suggestion given by user Samsotha, I implemented a simple filter, which is then "connected" via name binding, like:

@Path("whatever")
@MyNewFilter
public class WhateverResource {
...

And:

@MyNewFilter
public class MyNewFilterImpl implements ContainerRequestFilter {
  @Override
  public void filter(ContainerRequestContext context) {      
    if (... feature is enabled )) {
        ... nothing to do
    } else {
        context.abortWith(
                Response.status(Response.Status.NOT_IMPLEMENTED).entity("not implemented").build());
    }
}

The major advantage of this approach is the fact that one can annotate individual operations, but also a whole resource, such as my WhateverResource. The latter will make sure that any operation within that resource is going through the filter!

( further details can be found in any decent Jersey tutorial, like the one at baeldung )

Upvotes: 3

Related Questions