ChatGPT解决这个技术问题 Extra ChatGPT

Why use JAX-RS / Jersey?

Sorry, this questions sounds silly, but after developing some of my RESTful services using Jersey, I asked myself the question -- If REST is just an architecture, and not a protocol like SOAP, why do we need a specification like JAX-RS?

I actually googled for questions like "What is the difference between servlets and RESTful services over HTTP" and to sum up the community answers, I got:

RESTful service development (on Jersey) is an architecture, which inherently uses servlets. JAX-RS compliant tools like Jersey provide easy marshalling-unmarshalling of XML/JSON data, helping the developers. REST helps us use GET/POST/PUT/DELETE in a fashion that is far efficient than normal servlets.

According to these answers, I guess if I write a servlet which uses JAXB (for dealing with automatic serialization), and I efficiently use GET/POST/PUT/DELETE in my servlet code, I don't use a tool like Jersey, and hence JAX-RS.

I know I am terribly wrong passing this statement, please correct me.

PS: This doubt actually came in when I had to develop some RESTful services in PHP. After going on through some of the RESTful PHP codes, I realized they are just the same old PHP scripts, with some helper methods for handling XML/JSON.

Thanks for all your replies. But can someone just answer my first point ? Why do we need a specification for an "architecture"... maybe someone can just point me to any other architecture which provides a formal spec ?
Are you looking for more of a reason than simplicity (few lines of code) and portability (deploy to GlassFish, WebLogic, WebSphere, JBoss, etc)? You can develop a RESTful service using lower level specifications such as Servlets/JAXP/JDBC, but this generally involves more code than higher level specifications such as JAX-RS/JAXB/JPA.

r
ramazan polat

Why use JAX-RS / Jersey?

Short Answer

Because it makes the development of RESTful services easier.

Long Answer

JAX-RS is a standard that makes it easy to create a RESTful service that can be deployed to any Java application server: GlassFish, WebLogic, WebSphere, JBoss, etc.

JAX-RS is part of Java EE, and when JAX-RS is used with other Java EE technologies it becomes even easier to create your RESTful service:

EJB - A session bean is used as the service implementation and also handles the transaction semantics.

JAX-RS - Used to expose the session bean as a RESTful service

JPA - Used to persist the POJOs to the database. Note how the EntityManager is injected onto the session bean.

JAXB - Used to convert the POJO to/from XML (in GlassFish it can also be used to convert the POJO to/from JSON). JAX-RS by default handles the interaction with the JAXB implementation.

Sample JAX-RS Service

package org.example;

import java.util.List;

import javax.ejb.*;
import javax.persistence.*;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;

@Stateless
@LocalBean
@Path("/customers")
public class CustomerService {

    @PersistenceContext(unitName="CustomerService",
                        type=PersistenceContextType.TRANSACTION)
    EntityManager entityManager;

    @POST
    @Consumes(MediaType.APPLICATION_XML)
    public void create(Customer customer) {
        entityManager.persist(customer);
    }

    @GET
    @Produces(MediaType.APPLICATION_XML)
    @Path("{id}")
    public Customer read(@PathParam("id") long id) {
        return entityManager.find(Customer.class, id);
    }

    @PUT
    @Consumes(MediaType.APPLICATION_XML)
    public void update(Customer customer) {
        entityManager.merge(customer);
    }

    @DELETE
    @Path("{id}")
    public void delete(@PathParam("id") long id) {
        Customer customer = read(id);
        if(null != customer) {
            entityManager.remove(customer);
        }
    }

    @GET
    @Produces(MediaType.APPLICATION_XML)
    @Path("findCustomersByCity/{city}")
    public List<Customer> findCustomersByCity(@PathParam("city") String city) {
        Query query = entityManager.createNamedQuery("findCustomersByCity");
        query.setParameter("city", city);
        return query.getResultList();
    }

}

For More Information:

http://blog.bdoughan.com/2010/08/creating-restful-web-service-part-45.html


The term "session bean" is misleading here. As your code shows, the RESTful endpoint is supposed to be stateless. There is no session kept.
So, JAX-RS is more XML friendly based on your asnwer that JSON conversion is only available with GlassFish server? Thanks
Could anyone comment on difference with Springboot? Why use one over the other? Thanks
f
fury.slay

REST is an architecture, which inherently uses servlets.

No, it is not. REST is an architecture style which can be implemented using servlets, but does not inherently use them, nor inherently have anything to do with Java.

JAX-RS is a JSR Specification defining a Java API for RESTful Web Services.

Jersey is a specific implementation of JAX-RS.

As to whether to use Jersey or try to be compliant to the JAX-RS specification, that's sort of up to you. If it makes your work easier, great! If not no one's forcing you.


+1 Additional note: using JAX-RS is almost guaranteed to be far easier than rolling your own ReSTful implementation using servlets. That's the whole point of it.
@Ryan, Don : That's the entire purpose of this question - Do we need Jersey only to ease the above mentioned activities. And I know what is JAX-RS, I just want to know why are Java people offering a seperate API for this...PHP didnt offer any and still they are doing good it seems.
@WinOrWin: We could do everything in assembly, too, so why use Java? All I can say is write a ReSTful API both ways, and decide which you'd like to do over and over.