We will learn protocols, SOAP, RESTful, java web service implementation, JAX-WS and JAX-RS tutorials and examples.
Web service is a technology to communicate one programming language with another. For example, java programming language can interact with PHP and .Net by using web services. In other words, web service provides a way to achieve interoperability.

Java Web Services Tutorial

In this tutorial, you will be able to learn java web services and its specifications such as JAX-WS and JAX-RS.

There are two ways to write the code for JAX-WS by RPC style and Document style. Like JAX-WS, JAX-RS can be written by Jersey and RESTeasy. We will learn all these technologies.

we will see a lot of web services examples like JAX-WS example by RPC style, JAX-WS example by document style, JAX-RS example by Jersey and JAX-RS example by RESTeasy implementation.

Web Services Specifications: JAX-WS and JAX-RS.

JAX-WS ways to write- RPC Style and Document style

JAX-RS can be written by - Jersey and RESTeasy

What is Web Service

A Web Service is can be defined by following ways:

is a client server application or application component for communication.
method of communication between two devices over network.
is a software system for interoperable machine to machine communication.
is a collection of standards or protocols for exchanging information between two devices or application.

Let's understand it by the figure given below:

Types of Web Services

There are mainly two types of web services.

SOAP web services.
RESTful web services.

Web Service Components

There are three major web service components.

SOAP
WSDL
UDDI

SOAP

SOAP is an acronym for Simple Object Access Protocol.

SOAP is a XML-based protocol for accessing web services.

SOAP is a W3C recommendation for communication between applications.

SOAP is XML based, so it is platform independent and language independent. In other words, it can be used with Java, .Net or PHP language on any platform.

WSDL

WSDL is an acronym for Web Services Description Language.

WSDL is a xml document containing information about web services such as method name, method parameter and how to access it.

WSDL is a part of UDDI. It acts as a interface between web service applications.

WSDL is pronounced as wiz-dull.

UDDI

UDDI is an acronym for Universal Description, Discovery and Integration.

UDDI is a XML based framework for describing, discovering and integrating web services.

UDDI is a directory of web service interfaces described by WSDL, containing information about web services.

Advantages of Soap Web Services

WS Security: SOAP defines its own security known as WS Security.

Language and Platform independent: SOAP web services can be written in any programming language and executed in any platform.

Disadvantages of Soap Web Services

Slow: SOAP uses XML format that must be parsed to be read. It defines many standards that must be followed while developing the SOAP applications. So it is slow and consumes more bandwidth and resource.

WSDL dependent: SOAP uses WSDL and doesn't have any other mechanism to discover the service.

RESTful Web Services

REST stands for REpresentational State Transfer.

REST is an architectural style not a protocol.

Advantages of RESTful Web Services

Fast: RESTful Web Services are fast because there is no strict specification like SOAP. It consumes less bandwidth and resource.

Language and Platform independent: RESTful web services can be written in any programming language and executed in any platform.

Can use SOAP: RESTful web services can use SOAP web services as the implementation.

Permits different data format: RESTful web service permits different data format such as Plain Text, HTML, XML and JSON.

SOAP vs REST Web Services

There are many differences between SOAP and REST web services. The important 10 differences between SOAP and REST are given below:

No. SOAP vs REST

1) SOAP is a protocol.

REST is an architectural style.

2) SOAP stands for Simple Object Access Protocol.

REST stands for REpresentational State Transfer.

3) SOAP can't use REST because it is a protocol.

REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.

4) SOAP uses services interfaces to expose the business logic.

REST uses URI to expose business logic.

5) JAX-WS is the java API for SOAP web services.

JAX-RS is the java API for RESTful web services.

6) SOAP defines standards to be strictly followed.

REST does not define too much standards like SOAP.

7) SOAP requires more bandwidth and resource than REST.
REST requires less bandwidth and resource than SOAP.

8) SOAP defines its own security.

RESTful web services inherits security measures from the underlying transport.

9) SOAP permits XML data format only.

REST permits different data format such as Plain text, HTML, XML, JSON etc.

10)SOAP is less preferred than REST.

REST more preferred than SOAP.

Service Oriented Architecture (SOA)

Service Oriented Architecture or SOA is a design pattern. It is designed to provide services to other applications through protocol. It is a concept only and not tied to any programming language or platform. Web services is a technology of SOA most likely.

Service

A service is well-defined, self-contained function that represents unit of functionality. A service can exchange information from another service. It is not dependent on the state of another service.

Service Connections

The figure given below illustrates the service oriented architecture. Service consumer sends service request to the service provider and service provider sends the service response to the service consumer. The service connection is understandable to both service consumer and service provider.

Java Web Services Tutorial

Java web services tutorial provides concepts and examples of two main java web services api: JAX-WS and JAX-RS. The java web service application can be accessed by other programming languages such as .Net and PHP.

Java web service application perform communication through WSDL (Web Services Description Language). There are two ways to write java web service application code: SOAP and RESTful.

Java Web Services API

There are two main API's defined by Java for developing web service applications since JavaEE 6.

1) JAX-WS: for SOAP web services. The are two ways to write JAX-WS application code: by RPC style and Document style.

2) JAX-RS: for RESTful web services. There are mainly 2 implementation currently in use for creating JAX-RS application: Jersey and RESTeasy.

JAX-WS Tutorial

JAX-WS tutorial is provides concepts and examples of JAX-WS API.

There are two ways to develop JAX-WS example.

RPC style
Document style

JAX-RS Tutorial

JAX-RS tutorial is provides concepts and examples of JAX-RS API. This JAX-RS tutorial is designed for beginners and professionals.

There are two main implementation of JAX-RS API.

Jersey
RESTEasy

JAX-RS Example Jersey

We can create JAX-RS example by jersey implementation. To do so, you need to load jersey jar files or use maven framework.

In this example, we are using jersey jar files for using jersey example for JAX-RS.

There are created 4 files for hello world JAX-RS example:

Hello.java
web.xml
index.html
HelloWorldClient.java

The first 3 files are created for server side and 1 application for client side.

JAX-RS Server Code

File: Hello.java

package com.javatpoint.rest;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
@Path("/hello")
public class Hello {
// This method is called if HTML and XML is not requested
@GET
@Produces(MediaType.TEXT_PLAIN)
public String sayPlainTextHello() {
return "Hello Jersey Plain";
}
// This method is called if XML is requested
@GET
@Produces(MediaType.TEXT_XML)
public String sayXMLHello() {
return "<?xml version=\"1.0\"?>" + "<hello> Hello Jersey" + "</hello>";
}
// This method is called if HTML is requested
@GET
@Produces(MediaType.TEXT_HTML)
public String sayHtmlHello() {
return "<html> " + "<title>" + "Hello Jersey" + "</title>"
+ "<body><h1>" + "Hello Jersey HTML" + "</h1></body>" + "</html> ";
}
}

File: web.xml

<?xml version="1.0" encoding="UTF-8"?>  
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
xmlns="http://java.sun.com/xml/ns/javaee"   
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee   
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"   
id="WebApp_ID" version="3.0">  
 <servlet>  
    <servlet-name>Jersey REST Service</servlet-name>  
    <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>  
    <init-param>  
        <param-name>jersey.config.server.provider.packages</param-name>  
        <param-value>com.javatpoint.rest</param-value>  
    </init-param>  
    <load-on-startup>1</load-on-startup>  
  </servlet>  
  <servlet-mapping>  
    <servlet-name>Jersey REST Service</servlet-name>  
    <url-pattern>/rest/*</url-pattern>  
  </servlet-mapping>  
</web-app>   

File: index.html

<a href="rest/hello">Click Here</a>  

Now run this application on server. Here we are using Tomcat server on port 4444. The project name is restfuljersey.

After running the project, you will see the following output:

JAX-RS Client Code

The ClientTest.java file is created inside the server application. But you can run client code by other application also by having service interface and jersey jar file.

File: ClientTest.java

package com.javatpoint.restclient;
import java.net.URI;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.WebTarget;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.UriBuilder;
import org.glassfish.jersey.client.ClientConfig;
public class ClientTest {
public static void main(String[] args) {
ClientConfig config = new ClientConfig();
Client client = ClientBuilder.newClient(config);
WebTarget target = client.target(getBaseURI());
//Now printing the server code of different media type
System.out.println(target.path("rest").path("hello").request().accept(MediaType.TEXT_PLAIN).get(String.class));
System.out.println(target.path("rest").path("hello").request().accept(MediaType.TEXT_XML).get(String.class));
System.out.println(target.path("rest").path("hello").request().accept(MediaType.TEXT_HTML).get(String.class));
}
private static URI getBaseURI() {
//here server is running on 4444 port number and project name is restfuljersey
return UriBuilder.fromUri("http://localhost:4444/restfuljersey").build();
}
}

Output:

Hello Jersey Plain
<?xml version="1.0"?><hello> Hello Jersey</hello>
<html> <title>Hello Jersey</title><body><h1>Hello Jersey HTML</h1></body></html>

Click me to download JAX-RS example using eclipse without jersey jar files.

Click me to download jersey jar files.

What exactly is RESTful programming?

An architectural style called REST (Representational State Transfer) advocates that web applications should use HTTP as it was originally envisioned. Lookups should use GETrequests. PUT, POST, and DELETE requests should be used for mutation, creation, and deletion respectively.

REST proponents tend to favor URLs, such as

http://myserver.com/catalog/item/1729

but the REST architecture does not require these “pretty URLs”. A GET request with a parameter

http://myserver.com/catalog?item=1729

is every bit as RESTful.

Keep in mind that GET requests should never be used for updating information. For example, a GET request for adding an item to a cart

http://myserver.com/addToCart?cart=314159&item=1729

would not be appropriate. GET requests should be idempotent. That is, issuing a request twice should be no different from issuing it once. That’s what makes the requests cacheable. An “add to cart” request is not idempotent—issuing it twice adds two copies of the item to the cart. A POST request is clearly appropriate in this context. Thus, even a RESTful web application needs its share of POST requests.

This is taken from the excellent book Core JavaServer faces Book by David M. Geary

----------------------------------------------

Wife: Who is Roy Fielding?

Ryan: Some guy. He's smart.

Wife: Oh? What did he do?

Ryan: He helped write the first web servers and then did a ton of research explaining why the web works the way it does. His name is on the specification for the protocol that is used to get pages from servers to your browser.

Wife: How does it work?

Ryan: The web?

Wife: Yeah.

Ryan: Hmm. Well, it's all pretty amazing really. And the funny thing is that it's all very undervalued. The protocol I was talking about, HTTP, it's capable of all sorts of neat stuff that people ignore for some reason.

Wife: You mean http like the beginning of what I type into the browser?

Ryan: Yeah. That first part tells the browser what protocol to use. That stuff you type in there is one of the most important breakthroughs in the history of computing.

Wife: Why?

Ryan: Because it is capable of describing the location of something anywhere in the world from anywhere in the world. It's the foundation of the web. You can think of it like GPS coordinates for knowledge and information.

Wife: For web pages?

Ryan: For anything really. That guy, Roy Fielding, he talks a lot about what those things point to in that research I was talking about. The web is built on an architectural style called REST. REST provides a definition of a resource, which is what those things point to.

Wife: A web page is a resource?

Ryan: Kind of. A web page is a representation of a resource. Resources are just concepts. URLs--those things that you type into the browser...

Wife: I know what a URL is..

Ryan: Oh, right. Those tell the browser that there's a concept somewhere. A browser can then go ask for a specific representation of the concept. Specifically, the browser asks for the web page representation of the concept.

Wife: What other kinds of representations are there?

Ryan: Actually, representations is one of these things that doesn't get used a lot. In most cases, a resource has only a single representation. But we're hoping that representations will be used more in the future because there's a bunch of new formats popping up all over the place.

Wife: Like what?

Ryan: Hmm. Well, there's this concept that people are calling Web Services. It means a lot of different things to a lot of different people but the basic concept is that machines could use the web just like people do.

Wife: Is this another robot thing?

Ryan: No, not really. I don't mean that machines will be sitting down at the desk and browsing the web. But computers can use those same protocols to send messages back and forth to each other. We've been doing that for a long time but none of the techniques we use today work well when you need to be able to talk to all of the machines in the entire world.

Wife: Why not?

Ryan: Because they weren't designed to be used like that. When Fielding and his buddies started building the web, being able to talk to any machine anywhere in the world was a primary concern. Most of the techniques we use at work to get computers to talk to each other didn't have those requirements. You just needed to talk to a small group of machines.

Wife: And now you need to talk to all the machines?

Ryan: Yes - and more. We need to be able to talk to all machines about all the stuff that's on all the other machines. So we need some way of having one machine tell another machine about a resource that might be on yet another machine.

Wife: What?

Ryan: Let's say you're talking to your sister and she wants to borrow the sweeper or something. But you don't have it - your Mom has it. So you tell your sister to get it from your Mom instead. This happens all the time in real life and it happens all the time when machines start talking too.

Wife: So how do the machines tell each other where things are?

Ryan: The URL, of course. If everything that machines need to talk about has a corresponding URL, you've created the machine equivalent of a noun. That you and I and the rest of the world have agreed on talking about nouns in a certain way is pretty important, eh?

Wife: Yeah.

Ryan: Machines don't have a universal noun - that's why they suck. Every programming language, database, or other kind of system has a different way of talking about nouns. That's why the URL is so important. It let's all of these systems tell each other about each other's nouns.

Wife: But when I'm looking at a web page, I don't think of it like that.

Ryan: Nobody does. Except Fielding and handful of other people. That's why machines still suck.

Wife: What about verbs and pronouns and adjectives?

Ryan: Funny you asked because that's another big aspect of REST. Well, verbs are anyway.

Wife: I was just joking.

Ryan: It was a funny joke but it's actually not a joke at all. Verbs are important. There's a powerful concept in programming and CS theory called polymorphism. That's a geeky way of saying that different nouns can have the same verb applied to them.

Wife: I don't get it.

Ryan: Well.. Look at the coffee table. What are the nouns? Cup, tray, newspaper, remote. Now, what are some things you can do to all of these things?

Wife: I don't get it...

Ryan: You can get them, right? You can pick them up. You can knock them over. You can burn them. You can apply those same exact verbs to any of the objects sitting there.

Wife: Okay... so?

Ryan: Well, that's important. What if instead of me being able to say to you, "get the cup," and "get the newspaper," and "get the remote"; what if instead we needed to come up with different verbs for each of the nouns? I couldn't use the word "get" universally, but instead had to think up a new word for each verb/noun combination.

Wife: Wow! That's weird.

Ryan: Yes, it is. Our brains are somehow smart enough to know that the same verbs can be applied to many different nouns. Some verbs are more specific than others and apply only to a small set of nouns. For instance, I can't drive a cup and I can't drink a car. But some verbs are almost universal like GET, PUT, and DELETE.

Wife: You can't DELETE a cup.

Ryan: Well, okay, but you can throw it away. That was another joke, right?

Wife: Yeah.

Ryan: So anyway, HTTP--this protocol Fielding and his friends created--is all about applying verbs to nouns. For instance, when you go to a web page, the browser does an HTTP GETon the URL you type in and back comes a web page.

Web pages usually have images, right? Those are separate resources. The web page just specifies the URLs to the images and the browser goes and does more HTTP GETs on them until all the resources are obtained and the web page is displayed. But the important thing here is that very different kinds of nouns can be treated the same. Whether the noun is an image, text, video, an mp3, a slideshow, whatever. I can GET all of those things the same way given a URL.

Wife: Sounds like GET is a pretty important verb.

Ryan: It is. Especially when you're using a web browser because browsers pretty much just GET stuff. They don't do a lot of other types of interaction with resources. This is a problem because it has led many people to assume that HTTP is just for GETing. But HTTP is actually a general purpose protocol for applying verbs to nouns.

Wife: Cool. But I still don't see how this changes anything. What kinds of nouns and verbs do you want?

Ryan: Well the nouns are there but not in the right format.

Think about when you're browsing around amazon.com looking for things to buy me for Christmas. Imagine each of the products as being nouns. Now, if they were available in a representation that a machine could understand, you could do a lot of neat things.

Wife: Why can't a machine understand a normal web page?

Ryan: Because web pages are designed to be understood by people. A machine doesn't care about layout and styling. Machines basically just need the data. Ideally, every URL would have a human readable and a machine readable representation. When a machine GETs the resource, it will ask for the machine readable one. When a browser GETs a resource for a human, it will ask for the human readable one.

Wife: So people would have to make machine formats for all their pages?

Ryan: If it were valuable.

Look, we've been talking about this with a lot of abstraction. How about we take a real example. You're a teacher - at school I bet you have a big computer system, or three or four computer systems more likely, that let you manage students: what classes they're in, what grades they're getting, emergency contacts, information about the books you teach out of, etc. If the systems are web-based, then there's probably a URL for each of the nouns involved here: student, teacher, class, book, room, etc. Right now, getting the URL through the browser gives you a web page. If there were a machine readable representation for each URL, then it would be trivial to latch new tools onto the system because all of that information would be consumable in a standard way. It would also make it quite a bit easier for each of the systems to talk to each other. Or, you could build a state or country-wide system that was able to talk to each of the individual school systems to collect testing scores. The possibilities are endless.

Each of the systems would get information from each other using a simple HTTP GET. If one system needs to add something to another system, it would use an HTTP POST. If a system wants to update something in another system, it uses an HTTP PUT. The only thing left to figure out is what the data should look like.

Wife: So this is what you and all the computer people are working on now? Deciding what the data should look like?

Ryan: Sadly, no. Instead, the large majority are busy writing layers of complex specifications for doing this stuff in a different way that isn't nearly as useful or eloquent. Nouns aren't universal and verbs aren't polymorphic. We're throwing out decades of real field usage and proven technique and starting over with something that looks a lot like other systems that have failed in the past. We're using HTTP but only because it helps us talk to our network and security people less. We're trading simplicity for flashy tools and wizards.

Wife: Why?

Ryan: I have no idea.

Wife: Why don't you say something?

Ryan: Maybe I will.

REST is the underlying architectural principle of the web. The amazing thing about the web is the fact that clients (browsers) and servers can interact in complex ways without the client knowing anything beforehand about the server and the resources it hosts. The key constraint is that the server and client must both agree on the media used, which in the case of the web is HTML.

An API that adheres to the principles of REST does not require the client to know anything about the structure of the API. Rather, the server needs to provide whatever information the client needs to interact with the service. An HTML form is an example of this: The server specifies the location of the resource and the required fields. The browser doesn't know in advance where to submit the information, and it doesn't know in advance what information to submit. Both forms of information are entirely supplied by the server. (This principle is called HATEOAS: Hypermedia As The Engine Of Application State.)

So, how does this apply to HTTP, and how can it be implemented in practice? HTTP is oriented around verbs and resources. The two verbs in mainstream usage are GET and POST, which I think everyone will recognize. However, the HTTP standard defines several others such as PUT and DELETE. These verbs are then applied to resources, according to the instructions provided by the server.

For example, Let's imagine that we have a user database that is managed by a web service. Our service uses a custom hypermedia based on JSON, for which we assign the mimetype application/json+userdb (There might also be an application/xml+userdb and application/whatever+userdb - many media types may be supported). The client and the server have both been programmed to understand this format, but they don't know anything about each other. As Roy Fielding points out:

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types.

A request for the base resource / might return something like this:

Request

GET /
Accept: application/json+userdb

Response

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

We know from the description of our media that we can find information about related resources from sections called "links". This is called Hypermedia controls. In this case, we can tell from such a section that we can find a user list by making another request for /user:

Request

GET /user
Accept: application/json+userdb

Response

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

We can tell a lot from this response. For instance, we now know we can create a new user by POSTing to /user:

Request

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

Response

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

We also know that we can change existing data:

Request

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

Response

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Notice that we are using different HTTP verbs (GET, PUT, POST, DELETE etc.) to manipulate these resources, and that the only knowledge we presume on the clients part is our media definition.

PUT vs. POST in REST

up vote4054down vote favorite

1812

According to the HTTP/1.1 Spec:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line

In other words, POST is used to create.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URIdoes not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI."

That is, PUT is used to create or update.

So, which one should be used to create a resource? Or one needs to support both?

Overall:

Both PUT and POST can be used for creating.

You have to ask "what are you performing the action to?" to distinguish what you should be using. Let's assume you're designing an API for asking questions. If you want to use POST then you would do that to a list of questions. If you want to use PUT then you would do that to a particular question.

Great both can be used, so which one should I use in my RESTful design:

You do not need to support both PUT and POST.

Which is used is left up to you. But just remember to use the right one depending on what object you are referencing in the request.

Some considerations:

Do you name your URL objects you create explicitly, or let the server decide? If you name them then use PUT. If you let the server decide then use POST.
PUT is idempotent, so if you PUT an object twice, it has no effect. This is a nice property, so I would use PUT when possible.
You can update or create a resource with PUT with the same object URL
With POST you can have 2 requests coming in at the same time making modifications to a URL, and they may update different parts of the object.

An example:

I wrote the following as part of another answer on SO regarding this:

POST:

Used to modify and update a resource
POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/
Note that the following is an error:
POST /questions/<new_question> HTTP/1.1
Host: www.example.com/
If the URL is not yet created, you should not be using POST to create it while specifying the name. This should result in a 'resource not found' error because <new_question> does not exist yet. You should PUT the <new_question> resource on the server first.

You could though do something like this to create a resources using POST:
POST /questions HTTP/1.1
Host: www.example.com/
Note that in this case the resource name is not specified, the new objects URL path would be returned to you.

PUT:

Used to create a resource, or overwrite it. While you specify the resources new URL.

For a new resource:
PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/
To overwrite an existing resource:
PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

--------------------------------

Has REST architecture finally put JSP to rest ?

I remember my development manager's sarcastic laugh with his bouncing shoulders when I had tried to access JSP tags from Javascript ! :( That was my first web application project as an intern and I was learning all Servlets, JSP etc. after my short journey in plain java. I had gotten totally confused with crazy mix of HTML + CSS + Javascript + Java + Scriptlets + JSTL + Struts + whatever is missing in this list.. ! It took me some time to understand what exactly is going on with all these buzzwords of that time..

May be writing JSP is better than writing servlets with "out.println", may be writing JSTL/Struts is better than writing scriptlets, but whenever I looked at any JSP I always thought it was perfect example of "kitchen sink" ! Both kitchen sink and JSP kept on reminding me of each other for years ! And I still feel about JSP the same way !

In all this chaos, Sir Roy Fielding (@fielding) was contemplating to transform this restless world of web development into RESTful world with REST architectural style ! Thanks to him, we are seeing this beautiful architectural style which separates client code and server code so elegantly. It's like marriage made in heaven by giving freedom to each other !

For Those Who Don't Know REST :

For readers, who don't know REST, it's Representational State Transfer ! Still don't get it ? It is based on the concept that all web is made up of "Resources" and when we use web-site as user, we keep on changing the state of the application. So, in short, it's "representing the state of the application" which is "transferred" to the user. Also, we perform 4 basic operations on resources. These 4 operations are popularly called as CRUD, Create, Read, Update and Delete. These 4 operations are (usually) accomplished using POST, GET, PUT and DELETE methods of the HTTP protocol.

Why REST ? :

Current device-diversity and the numerous development platforms have made sure you don't have any other way (mostly) than to go the REST way. And new HTML5 capabilities, increase in javascript efficiency and iOS/Android native platforms have made it easier to go REST way. REST has made the server a real server as its name suggests and has been given the responsibility of doing back end stuff only. So now server just provides data and thats what it should do ! It has nothing to do with HTML, CSS and client side Javascript. So there is no JSP where web designers and server engineers both try to cram in their art ! Though CSS makes web designer's silo to play, not everything can be isolated so much in this JSP model.

It's not just advantages of client/server code isolation and cleaner code, there are so many other advantages in this modern world of application development using RESTful style.. Of course, reader should keep in mind that the REST is a "style" not a "specification", so nothing is wrong or right in REST! (and actually I don't like to say this, sounds so clumsy but.. )

Here are some of those

RIP that troublesome session object on server side !: REST is stateless. Good REST design sends user-id and password in every request ! Or at least uses cookies in web-friendly client. So there is no need of long living session object on server side. User is authenticated every time and user data is live only for that request. In today's high performance hardware, authenticating user every time is not at all big burden compared to the advantages it brings.
Cloud computing friendly: Advantages of above fact ? It helps us to RIP those session replication needed for failover as well ! Less memory requirements on server side because no more session objects of million of users. Plus, adding virtual machines in cloud is now does not have the complexity of adding those machines as session buddies in those jboss-like application servers ! So simple round-robin load balancing could be good enough.
Readable and cacheable URLs :Unlike usual web application URL, where parameters are in the URL itself, REST application web URL is clean because all parameters take form of request body rather than the URL and submitted in the form of Json/XML object. Typical URL can be like http://www.example.com/appName/resource/<resource-id>. Being clean URLs, resources can be cached in better way than parameter based URLs.
Versioning freedom (at least in pure REST) :Original definition of REST likes client application start from root URL and subsequently get URLs of further resources. It avoids client to have pre-defined sets of URLs to avoid continuous changes in client code if server URI changes. This is also calledHATEOAS(what a scary looking word by the way). It means Hypermedia As The Engine Of Application State. Server provides hypermedia as the state of the application. So even if there is any change in URLs, client does not need to know since client only follows the path provided through server provided objects.

Practical REST :

Though ideal/pure REST promotes HATEOAS as mentioned above, practical problem is, that the communication becomes too chatty. It may end up making hundreds of calls to just show personalized front-page for the user. So many practical people go for fixed API. They handle versioning in different ways. For example www.example.com/v2 or v2.example.com etc.

For this approach, client code needs to change every time there is change in URL. But some avoid this problem by just adding new version related attributes in the payload itself. Next version clients can use those extra/new information, old version client will get the same payload but would not even know what the extra attributes are and will just keep ignoring it.

Everywhere REST:

Now most of the leading code generators like Spring Roo, Play framework use RESTful URLs, even in traditional model of JSP (by keeping URLs RESTful ).
New world of Micro-Services is based on RESTful interaction between those services. New initiatives like Spring Boot helps create REST applications quickly using embedded servlet containers making micro-services easy to develop.
Spring now now also has Async support for REST using AsyncRestTemplate.
Almost all Javascript libraries support RESTful calls. Spring now has getting started guides for many Javascript frameworks for consuming RESTful services based on Spring as backend. For example, Spring REST with angular.js https://spring.io/guides/gs/consuming-rest-angularjs

Conclusion : Pay Your Respects For JSP ! :)

-------------------------------------------------------------------------

What is the difference between normal Spring MVC and Spring RESTful web service?

Spring MVC is Spring Framework's own web framework that has been designed around Dispatcher Servlet, which intercepts the incoming requests and passes them on to the handlers, from where the controller takes care of the rest. You can follow this link to understand the complete Spring MVC flow.

Spring REST architecture is also based on Spring MVC, slightly making the difference on the View part. Traditional Spring MVC relies on the View technology to render the model data, the Spring REST architecture also does the same, except that the model object is set directly into the HTTP response, which the @ResponseBody converts into JSON/XML automatically. The output of a RESTful web service has to be a JSON or an XML, a standard format that could be easily handled across different consumer application platforms.

In higher Spring versions, the @RestController can directly be used instead of @Controller and @ResponseBody.

Hope this answers the query well.

--------

Normally the flow of Spring MVC Requires you to bind the controller and view tightly i,e Spring MVC manages the view data.

While in case of Rest using Spring MVC, Spring is only used for exposing data via Rest APIs, These APIs can be consumed by any type of view(Like via Ajax Request from view), Not neccesarily managed by spring.

Specifically it is used when you want to fetch data via ajax. Normal pattern for such type of architecture involves exposing a REST API using Rest Controllers from Spring and using ajax consuming these APIs on views.

----

In simple words,

Spring MVC : is a Model-View-Controller framework to build web application using different view technologies like JSP, JSTL, Tiles, etc

Spring Restful : is also a Model-View-Controller framework but adding few annotations like @RestController, @RequestBody, @ResponseBody turns into REST web service

To conclude, Spring Restful service has both Spring MVC and Rest web service capabilities

Check below articles,

Spring MVC

Spring REST service

---

The key difference between a traditional Spring MVC @Controller and the RESTful web service @RestController is the way the HTTP response body is created. While the traditional MVC controller relies on the View technology, the RESTful web service controller simply returns the object and the object data is written directly to the HTTP response as JSON/XML by registered HttpMessageConverters.

Spring MVC

Spring REST

-----------------------------------------------------------------------------------------------

Difference between JAX-RS and Spring Rest

I confused with the difference between JAX-RS (well, maybe should use Jersey to do comparison since JAX-RS is just spec) and Spring for Restful services. I tried to search for more information online and it become more confusing. My company is using Spring MVC to develop Restful APIs

The confusing part is, JAX-RS stands for Java API for RESTful Web Services, in Spring i am also using java to develop RESTful Web Services, so i don't actually get the differences. Is Spring follows the JAX-RS specifications?

From what i know until now:

JAX-RS is a blueprint/specification, it has Jersey, RESTeasy, etc as implementations.

JAX-RS

JAX-RS is a specification for implementing REST web services in Java, currently defined by the JSR-370. It is part of the Java EE technologies, currently defined by the JSR 366.

Jersey (shipped with GlassFish and Payara) is the JAX-RS reference implementation, however there are other implementations such as RESTEasy (shipped with JBoss EAP and WildFly) and Apache CXF (shipped with TomEE and WebSphere).

Spring Framework

The Spring Framework is a full framework that allows you to create Java enterprise applications. The REST capabilities are provided by the Spring MVC module (same module that provides model-view-controller capabilities). It is not a JAX-RS implementation and can be seen as a Spring alternative to the JAX-RS stardard.

The Spring ecosystem also provides a wide range of projects for creating enterprise applications, covering persistence, security, integration with social networks, batch processing, etc.

Examples

Consider the following resource controller using the JAX-RS API:

@Path("/greetings")
public class JaxRsController {

    @GET
    @Path("/{name}")
    @Produces(MediaType.TEXT_PLAIN)
    public Response greeting(@PathParam("name") String name) {

        String greeting = "Hello " + name;
        return Response.ok(greeting).build();
    }
}

The equivalent implementation using the Spring MVC API would be:

@RestController
@RequestMapping("/greetings")
public class SpringRestController {

    @RequestMapping(method = RequestMethod.GET,
                    value = "/{name}", 
                    produces = MediaType.TEXT_PLAIN_VALUE)
    public ResponseEntity<?> greeting(@PathVariable String name) {

        String greeting = "Hello " + name;
        return new ResponseEntity<>(greeting, HttpStatus.OK);
    }
}

Using Spring Boot and Jersey

Spring Boot provides the spring-boot-starter-jersey module that allows you to use the JAX-RS programming model for the REST endpoints instead of Spring MVC. It works quite well with Jersey 2.x.

For a complete example of creating a web application with Jersey 2.x and Spring Boot 1.4.x, refer to this answer.

----------

you mentioned that The Spring Framework is not a JAX-RS implementation, which specification is Spring following?

It does not implement any particular specification. It's just the Spring way of doing the things. REST capabilities are provided by the spring-webmvc module that also provides the Spring’s model-view-controller.

--------------------------------------------------------------

REST web services are used to decouple web service with the client. Many developer has used either Spring or JAX-RS for this purpose. JAX-RS stands for Java API for RESTful Web Services. It was specifically created to make writing REST resources easier.

--------------------------

Difference between web services and web application

Lets have an example scenario:

Client opens a web site and finds the sum of two numbers which he enters from the textboxes.Then clicks on the ADD button.Two parameters are HTTP GET'ed to server where PHP code is written to add the numbers and result is echo'ed.

Based on this scenario could anybody explain the difference between Web services and application?

In your case if you have User Interface for providing two numbers and then getting the result, it should be called a web application. But if you have an API exposed to receive two numbers and return result over http , then it should be called a web service.
At low level, both Web application and web service are kind of same thing. But the main point is that web services are for machine/program to machine/program communication whereas Web application is for Users.

So, basically web applications have user interfaces whereas web services don't, right?

it is not that simple, there are applications without UI like Windows Services. The main point is that web services are for machine to machine or application to application communication.

I'd say that web applications are intended for users and web services are intended for other applications. That's the most important difference. Web applications usually present data in HTML which looks nice to the user and web services usually present data in XML which easy to parse by other applications.

A person drives a car. That car could be powered by an internal combustion engine, electric motor, or nuclear reactor. The power source doesn't matter to the driver though, as all they need to see are the controls and the road ahead.

The application is the car. Web services are the nuclear reactor.

To add 2 no.s we write a web service, to subtract we write a diffrent web service, however calculator is an web application that uses add,subtract and many other webservices in combine.

User interacts with web application while machine interacts with web service.
To access web application, one must visit application. While web service can be access from anywhere (from any application which integrated it). We don't need to visit the service explicitly.

A webservice is equivalent to a method in java that has a web wrapper around it. It lives on the server and it can be sent data / queried etc. and may or may not return a result. It does not have any front end it can only be accessed via http get, put, delete etc.

A web Application is a fully functional piece of software that lives on a sever that is designed to help people achieve a task. This would have a front end that would allow users to interact with it / enter data etc.

A web application could use multiple webservices to achieve its goal / end result.

There is little difference between web application and web services. Web Application: In web application when user request any data then the server embeds the response into some HTML and forward it to the user and on browser the HTML is rendered. While in web services it's done differently that when some user requests for some data then the server returns it a json or XML array of objects and the data can be displayed by anyway the web designers wants.

Web Application

A web application is a software application that a user runs in the web browser. It have the following features.

It has a User Interface
Runs in Client - Server environment
Client runs it with the help of a web browser
Server process the data based on client request and provide response

Web Service

A web service is an Application Program Interface (API) that runs on the server, which provide data to the client over http through a standardized messaging system. (XML, JSON, etc...). Web services are further classified into SOAP and REST. In the present day scenario most services prefer REST over SOAP.

Example

I'll explain a simple REST call using a GET request to the github api. You can access the details of a github user with the following request

$h t t p s : / / a p i . g i t h u b . c o m / u s e r s / < u s e r - n a m e >$

See My details in JSON format from GitHub. Click Here And such data can be integrated into a web application, mobile app, etc.

Some other use cases of Web Services are

Conclusion

Both Web Application and Web Service are a kind of same thing, but web application is for the users and Web Service is for Program <==> Program communication.

Any application which you can run in your web browser is a web application or web app. So basically, all the websites you see and visit daily are web apps. Quora itself is a web app if you are opening it in your web browser.

Web service however is the one which your apps (web as well as mobile) as well as other apps (if you provide access) can use. For example, you can put Facebook's 'Like' button in any website or you can provide 'Login' functionality through Facebook that is because Facebook has exposed this functionality as a web service which it itself uses and others can also use by registering their app with Facebook.

So basically a web service can be consumed by any app be it web, mobile or desktop.

---------------

What tools do you use to test your public REST API? [closed]

73down vote favorite

Looking for tools use to test REST API.

So far I'm only aware of SoapUI. I've tried SOAPUI but - at least in a mac - it's terrible.

Wondering what people are using to test their own APIs.

JMeter is the best tool for REST API testing - Adding this comment for people who are looking for some detailed steps to test a REST API using JMeter. testautomationguru.com/how-to-test-rest-api-using-jmeter – vins

59down vote

If you're just testing your APIs manually, we've found RestClient 2.3 or the Poster add-on for Firefox to be pretty helpful. Both of these let you build requests that GET, PUT, POST, or DELETE. You can save these requests to rerun later.

For simple automated testing try the Linux (or Cygwin) 'curl' command in a shell script.

From something more industrial strength you can move up to Apache JMeter. JMeter is great for load testing.

31 October 2014: HTTPRequester is now a better choice for Firefox.

July 2015: Postman is a good choice for Chrome

37down vote

Postman in the chrome store is simple but powerful.

------------------------------------

An API or Application programming interface is a collection of software functions and procedures through which other software applications can be accessed or executed. In API Testing you use software to send calls to the API, get output and log the system's response. For Agile development, Api Testing becomes important as shorter development cycles put more pressure on automated testing.

1) Tricentis

Top 6 API Testing Tools In 2017: REST & SOAP

Tricentis is a robust web services testing tool. Prominent API Testing features of Tricentis Tosca are –

It supports a wide array of protocols including HTTP(s) JMS, AMQP, Rabbit MQ, TIBCO EMS, SOAP, REST, IBM MQ,NET TCP
It intergrates into the Agile and DevOps Cylce
It uses model-based test automation that makes script maintenance easy.
Enables end-to-end testing as API tests can be used across mobile, cross-browser, packaged apps, etc.

Tricentis’ 400+ customers include global names from the Top 500 brands such as ExxonMobil, HBO, Whole Foods, Toyota, Allianz, BMW, Starbucks, Deutsche Bank, Lexmark, Orange, A&E, Vantiv, Vodafone, Telstra and UBS.

2) SOAP UI

The most widely popular tool for API testing in the world, SoapUI allows you to test REST and SOAP APIs with ease – as it has been built specifically for API testing.

Quick and Easy Test Creation: Point-and-click, drag-and-drop, functionality makes complicated tasks (like working with JSON and XML) simple
Powerful data-driven testing: Load data from Excel, files, and databases to simulate the way consumers interact with your APIs
Reusability of Scripts: Reuse your functional test cases as load tests and security scans in just a few clicks
Seamless Integrations: Integrates with 13 API management platforms, supports REST, SOAP, JMS, and IoT

SoapUI NG Pro is used by thousands of leading companies around the world, including: Apple, Microsoft, Cisco, Oracle, HP, NASA, eBay, MasterCard, Intel, FedEx, and Pfizer

3) HP QTP(UFT)

It provides an extensible framework helpful in executing and building the functionality of headless system that do not have a user interface. It helps to test the headless technologies like Databases and Webservices, JMS, etc. By using the API test conversion tool, you can convert soapUI tests to UFT (QTP) API tests.

4) Parasoft

Parasoft is a feature-rich SOAP testing tool. It provides an interface for automating complex scenarios across the messaging layer, databases, ESBs, and mainframes. Determing automated test scenarios across the broad range of protocols and message used in APIs, REST, WADL, JSON, etc.

It is created in a manner to simplify testing of GUI-less APIs
It creates extensible, reusable, easily maintainable tests with 100% coverage
It designs sophisticated tests without scripting or coding
It automates continuous regression testing with sophisticated validations
It has broad support for platforms, technologies and protocols

5) vREST

vREST provides an online solution for automated testing, mocking, automated recording and specification of REST/HTTP APIs/RESTful APIs.

It provides an exhaustive tool to quickly validate your REST APIs
It delivers zero defect web applications with less effort in API testing
To validate your web application no skilled resources are required, and it can generate documentation for your API specifications
API mocks can be created in vREST with the help of Mock Server Functionality. User can directly start developing frontend using mock HTTP requests

6) Postman

Postman is a plugin in Google Chrome, and it can be used for testing API services. It is a powerful HTTP client to test web services. For manual or exploratory testing, Postman is a good choice for testing API.

With Postman, almost all modern web API data can be extracted
You can write Boolean tests within Postman Interface
You can create a collection of REST calls and save each call as part of a collection for execution in future
Unlike CURL, it is not a command line based tool, which makes this tool hassle free of pasting text into command line window
For transmitting and receiving REST information, Postman is more reliable

7) HttpMaster

It is a web development tool to automate web application testing, including API testing, service testing and website testing. It is primarily used as web API test tool to automate testing of web API calls.

HttpMaster is a best choice for API testing as it has got

Several http methods (GET, POST, DELETE etc.)
Dynamic parameters of various data types to make batches of different API requests
Various validation types and advanced validation expressions

8) Rest-assured

It’s a popular framework to test REST services in Java.

---------------

JAX-RS vs Spring Rest

19down vote favorite

From what i know until now:

JAX-RS is a blueprint/specification, it has Jersey, RESTeasy, etc as implementations.

asked Mar 22 '17 at 7:01

hades

4851521

@CássioMazzochiMolin thanks for your answer, i will accept it in a while more, one more question, you mentioned that The Spring Framework is not a JAX-RS implementation, which specification is Spring following? Thanks – hades Mar 23 '17 at 9:10

add a comment

3 Answers

active oldest votes

up vote31down voteaccepted

JAX-RS

JAX-RS is a specification for implementing REST web services in Java, currently defined by the JSR-370. It is part of the Java EE technologies, currently defined by the JSR 366.

Spring Framework

The Spring ecosystem also provides a wide range of projects for creating enterprise applications, covering persistence, security, integration with social networks, batch processing, etc.

Examples

Consider the following resource controller using the JAX-RS API:

@Path("/greetings")
public class JaxRsController {

    @GET
    @Path("/{name}")
    @Produces(MediaType.TEXT_PLAIN)
    public Response greeting(@PathParam("name") String name) {

        String greeting = "Hello " + name;
        return Response.ok(greeting).build();
    }
}

The equivalent implementation using the Spring MVC API would be:

@RestController
@RequestMapping("/greetings")
public class SpringRestController {

    @RequestMapping(method = RequestMethod.GET,
                    value = "/{name}", 
                    produces = MediaType.TEXT_PLAIN_VALUE)
    public ResponseEntity<?> greeting(@PathVariable String name) {

        String greeting = "Hello " + name;
        return new ResponseEntity<>(greeting, HttpStatus.OK);
    }
}

Using Spring Boot and Jersey

Spring Boot provides the spring-boot-starter-jersey module that allows you to use the JAX-RS programming model for the REST endpoints instead of Spring MVC. It works quite well with Jersey 2.x.

For a complete example of creating a web application with Jersey 2.x and Spring Boot 1.4.x, refer to this answer.

edited Nov 27 '17 at 13:22

answered Mar 22 '17 at 15:08

Cassio Mazzochi Molin

35.5k1067125

add a comment

up vote9down vote

I worked with both Jersey Rest, spring rest and Jersey Rest with spring. Both of them are very rich frameworks with nice implementations. I would suggest it's better to go with Spring rest if you are using other Spring services such as ORM ,Spring security and DI etc. Both are spring libraries so I feel little bit essay for managing code and dependencies

JAX-RS pros:

JSR standard can be run without servlet container (grizzly, simple, ...)
Production-ready implementations (jersey, cxf, resteasy, restlet, ...) designed for REST applications only

Spring MVC pros:

Provide "full" stack, not just REST facilities
Dependency injection / AOP / Transactions
Pluggable view templates (JSP, freemarker, velocity, ...)

You can check more on the following links

JAX-RS is the specification and jersey etc are are its implementation. People use Spring to make RestFul web Services as because spring along with restful implementation provides stuff like hibernate integration and also stuff like IOC and Aspect orientated programming .

Where as if we use jersey for our implementation the problem will be the data has to fetched from the back end using some ORM technologies and we will have to write boilerplate code for the same.

That is the reason people and even enterprises use spring as along with Rest implementation it provides Spring facilities too . And now using the latest Spring boot implementation we can start development very fast without lots of configurations.

-----------------------

Spring MVC is a full Web frontend framework including support for HTML and other templating, plus other features, in addition to the JSON/XML REST features provided by Jersey.

Spring MVC was around first and has its own way of doing things. JAX-RS was defined as a standard for annotation-based REST handlers, and Jersey is an implementation of that standard. (It's very similar to @Autowired and CDI.)

I personally prefer Spring MVC because I build on a Spring stack and can reuse code between my JSON and HTML handlers, but components intended to be deployed as one part of a customer's own system might be more flexible if using JAX-RS.

----------------------

up vote94down vote favorite

We are planning to make a new application with spring 4.0.6 version. We use controller that can return "XML" or "JSON". In the previous project we have successfully implemented Jersey with Spring for REST support using JAX-RS API, but after reading a few articles and suggestions from seniors they said spring is providing pretty good REST support.

Some of the points that really confused me if I use Spring REST support without using JAX-RS and Jersey are:

How marshaling and unmarshaling done in Spring MVC ?
Is it necessary for marshaling or unmarshaling need to use jax-rs.
If marshaling and unmarshaling are automatically handled by spring then how does it know about xmlRootElements.

I am still confused if Spring proving very good support of REST then why do people still go with Jersey for REST? Really looking to know more in details.

If I said anything wrong please ignore it. Explanation with example is really helpful.

Thanks in advance!!

edited May 11 '16 at 10:29

Cassio Mazzochi Molin

35.5k1067125

asked Oct 10 '14 at 17:59

Robin Saxena

6861612

add a comment

2 Answers

active oldest votes

up vote95down voteaccepted

I'd say both Jersey and Spring MVC are great - each project has its own style and strengths. Anyway, Stack Overflow is not the right place for asking subjective comparisons (your question would be closed quite quickly). If you're already using Spring for everything else and are not required to use JAX-RS, then Spring MVC makes total sense.

Regarding features like (un)marshalling, JAX-RS is just a spec after all - other libraries can offer similar features without implementing the same API.

Instead of MessageBodyReaders/Writers, Spring MVC is using HttpMessageConverters to handle (un)marshalling REST resources. Spring MVC handles content negotiation and chooses the best available converter for the job (you can annotate methods to hint at what media type they produce/consume).
No, it's not necessary to use JAX-RS to (un)marshall resources. In fact, JAX-RS implementations and Spring MVC use third party serialization libraries to do the job; so it's not tied to a particular standard.
In its 4.0.6 version, Spring supports many HttpMessageConverters, with Jackson for JSON, JAXB for XML and many others. Spring 4.1.0 added more HttpMessageConverters:
- Jackson is now available for both JSON and XML
- Google Protobuf
- Gson for JSON, as an alternative to Jackson

To answer your last point, @XmlRootElement is a JAXB annotation and is not part of JAX-RS. Spring supports JAXB.

For a more complete example with REST in Spring, check out this getting started guide (you'll get a complete example running in 10-15 minutes).

Again the last part of your question is quite subjective - there are many popular solutions for building REST services in the JVM, not just Jersey and Spring (Dropwizard, Play! Framework, etc).

Where would you suggest someone ask a question like this? – Steven Wade Apr 15 '16 at 15:48

@StevenWade Quora? Redit? – James111 Jun 8 '16 at 4:05

"your question would be closed quite quickly"! Not that quick :) – Afshin Moazami Dec 5 '16 at 16:16

I have love stackoverflow and i love quora, i have never liked this closing subjective question policy and I have never thought about asking technical questions in quora – Kalpesh Soni Apr 6 '17 at 18:04

add a comment

up vote21down vote

AFAIK Spring REST support is based on Spring MVC and its not JAX-RS implementation while Jersey has implemented JAX-RS specification. Those having Spring (Core, AOP or MVC) in their project chooses Spring ReST support over JAX-RS implementor.

I recommend Jersey as its mature, implements JAX-RS and is easy to use.

-----------------

66down vote favorite

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.

edited Apr 23 '15 at 11:09

Jens Piegsa

4,26243071

asked Aug 13 '11 at 17:34

WinOrWin

1,00431324

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 ?– WinOrWin Aug 15 '11 at 6:20

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. – Blaise Doughan Aug 15 '11 at 13:29

add a comment

2 Answers

active oldest votes

up vote60down voteaccepted

Why use JAX-RS / Jersey?

Short Answer

Because in 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

edited Oct 29 '12 at 11:26

answered Aug 14 '11 at 12:47

Blaise Doughan

122k12204298

add a comment

up vote48down vote

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.

-----------------

up vote19down vote favorite

From what i know until now:

JAX-RS is a blueprint/specification, it has Jersey, RESTeasy, etc as implementations.

asked Mar 22 '17 at 7:01

hades

4851521

add a comment

3 Answers

active oldest votes

up vote31down voteaccepted

JAX-RS

JAX-RS is a specification for implementing REST web services in Java, currently defined by the JSR-370. It is part of the Java EE technologies, currently defined by the JSR 366.

Spring Framework

The Spring ecosystem also provides a wide range of projects for creating enterprise applications, covering persistence, security, integration with social networks, batch processing, etc.

Examples

Consider the following resource controller using the JAX-RS API:

@Path("/greetings")
public class JaxRsController {

    @GET
    @Path("/{name}")
    @Produces(MediaType.TEXT_PLAIN)
    public Response greeting(@PathParam("name") String name) {

        String greeting = "Hello " + name;
        return Response.ok(greeting).build();
    }
}

The equivalent implementation using the Spring MVC API would be:

@RestController
@RequestMapping("/greetings")
public class SpringRestController {

    @RequestMapping(method = RequestMethod.GET,
                    value = "/{name}", 
                    produces = MediaType.TEXT_PLAIN_VALUE)
    public ResponseEntity<?> greeting(@PathVariable String name) {

        String greeting = "Hello " + name;
        return new ResponseEntity<>(greeting, HttpStatus.OK);
    }
}

Using Spring Boot and Jersey

Spring Boot provides the spring-boot-starter-jersey module that allows you to use the JAX-RS programming model for the REST endpoints instead of Spring MVC. It works quite well with Jersey 2.x.

For a complete example of creating a web application with Jersey 2.x and Spring Boot 1.4.x, refer to this answer.

edited Nov 27 '17 at 13:22

answered Mar 22 '17 at 15:08

Cassio Mazzochi Molin

35.5k1067125

add a comment

up vote9down vote

JAX-RS pros:

JSR standard can be run without servlet container (grizzly, simple, ...)
Production-ready implementations (jersey, cxf, resteasy, restlet, ...) designed for REST applications only

Spring MVC pros:

Provide "full" stack, not just REST facilities
Dependency injection / AOP / Transactions
Pluggable view templates (JSP, freemarker, velocity, ...)

You can check more on the following links

edited Nov 8 '17 at 12:31

Amarnath

6,13973671

answered Mar 22 '17 at 13:08

Midhun Pottammal

301114

However, JAX-RS can be used with Spring (for DI, AOP, ...), too. – deamon Jul 10 '17 at 7:38

add a comment

up vote2down vote

Where as if we use jersey for our implementation the problem will be the data has to fetched from the back end using some ORM technologies and we will have to write boilerplate code for the same.

Java Technology - 2018 - WebServices

Java Web Services Tutorial

What is Web Service

Types of Web Services

Web Service Components

SOAP

WSDL

UDDI

Advantages of Soap Web Services

Disadvantages of Soap Web Services

RESTful Web Services

Advantages of RESTful Web Services

SOAP vs REST Web Services

Service Oriented Architecture (SOA)

Service

Service Connections

Java Web Services Tutorial

Java Web Services API

JAX-WS Tutorial

JAX-RS Tutorial

JAX-RS Example Jersey

JAX-RS Server Code

JAX-RS Client Code

Has REST architecture finally put JSP to rest ?

For Those Who Don't Know REST :

Why REST ? :

Practical REST :

Everywhere REST:

What is the difference between normal Spring MVC and Spring RESTful web service?

JAX-RS

Spring Framework

Examples

Using Spring Boot and Jersey

Top 6 API Testing Tools In 2018: REST & SOAP

1) Tricentis

2) SOAP UI

3) HP QTP(UFT)

4) Parasoft

5) vREST

6) Postman

7) HttpMaster

8) Rest-assured

3 Answers

JAX-RS

Spring Framework

Examples

Using Spring Boot and Jersey

2 Answers

2 Answers

3 Answers

JAX-RS

Spring Framework

Examples

Using Spring Boot and Jersey

Comments

Post a Comment

Popular posts from this blog