All geek questions in one place

RESTful Jersey Services: Resources and Answers

I see many Jersey-based web services consisting of 1+ WebResources that have 1+ endpoints / methods:

 package com.myws.fizz; public class FizzResource { @GET @Path("/fizz/{id}") public Response getFizzById(@PathParam("id") Long id) { // ...etc. } @GET @Path("/fizz") public Fizz getFizzByFoo(Foo foo) { // ...etc. } } package com.myws.buzz; public class BuzzResource { @POST @Path("/buzz") public Response createBuzz(Buzz buzz) { // ...etc. } }
  • I am confused by what Jersey considers to be a “resource." Is there a connection between the "resource" and the database? Table? POJO?
  • When do you return Response vs POJO? Take a look at my 2 getFizz methods above. When will I return Fizz and when will I return Response ?
+5
source share
1 answer

The term “Resource” is not just a Jersey term, as it is a REST term. When working with REST, we have Resources and Views . A resource can be any, and in this context it is some kind of object located on a server with a URL location. When a client requests a resource, we send it back. You are asking:

Is there a connection between the "resource" and the database? Table? POJO?

It could be a database (this thing). And we could just imagine it as a JSON object with the database name. It can also be a table (this thing). And we could represent it as a JSON object with column names and names. It could be a row in a table, and we can represent this using a JSON object with column names as keys and row values ​​as JSON values. It can be a web page, image, whatever. Therefore, I hope you understand that a resource can be anything. What we send back is its representation.

But the term resource is not limited only to returning something to the client’s request. The customer can also send us a resource submission, say create a new resource (POST) or modify an existing resource (PUT). A client can send us a JSON representation of a string (resource) in our database.

When do you return Response vs POJO? Take a look at my 2 getFizz methods above. When will I return Fizz and when will I return Response ?

Return Response allows you to fine tune Response . When a client makes a request, they always get a response. Answers have headings and bodies of a legal entity. When the type of the return method of the Fizz resource, you say that the body type of the entity will be of the Fizz type. When the method returns, what actually happens is that the Fizz object is not returned directly to the requesting client, by itself. Behind the scenes, it ends in Response , which is sent back to the client. The structure sets the headers that it considers necessary.

So, whether we decide to return Response or Fizz , it will be wrapped in Response . And, as I said, when we return Response , this allows us to fine-tune Response by adding our own headers, status codes, etc. For example, say someone did a POST . You could do something like

 @POST @Path("/buzz") @Produces(...) public Response createBuzz(Buzz buzz, @Context UriInfo uriInfo) { int buzzID = // create buzz and get the resource id UriBuilder builder = uriInfo.getAbsolutePathBuilder(); builder.path(Integer.toString(buzzId)); // concatenate the id. return Response.created(builder.build()).build(); }

Basically, what this does is create a resource, say in the database, and we get the return identifier. We can use the identifier to combine the URI with the identifier, this will be the new location of the resource. In terms of Response .created(...) it says that the status code must be 201 Created , and the value that we pass to created is the location of the newly created resource. This location will be set as the Location header in the response. So let's say that the path to the POST request is http://blah.com/buzz . What we would send back is http://blah.com/buzz/100 , where 100 is buzzId , and this full URL is how we will access the buzz resource, say using GET request to the resource method annotated with the words @GET @PATH("/buzz/{id}")

In terms of a GET , with Response , we could do

 Fizz newFizz = fizzService.getFizz(); return Response.ok(newFizz).build(); // sends the Fizz as the entity body

It really isn't that much different than just returning newFizz from a method, because we are not doing anything special with Response . We just say that the status code should be 200 OK and attach the body of the object. This is what usually happens with a successful GET request. Therefore, if we simply return Fizz instead of Response , in case of a successful GET, the structure will implicitly attach the status of 200 OK.

Personally, I prefer to return Responses due to tweaking.

+7
source

Source: https://habr.com/ru/post/978023/

More articles:


All Articles