Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
Yesterday I had an interview and I faced an interesting question where I got stuck.
The Question "How can you say Restful web service is a web service?". I was trying to explain all the possible ways to prove. But all the answers were blocked by the question "Servlets can do the same. So Servlets are restful web service?"
Can anyone share your thoughts?
To answer your question, lets ask first what is a web service?
In purely abstract terms,
A web service is a method of communication between two electronic
devices over the World Wide Web. (Wikipedia)
Now the accepted industry norm for the two devices to communicate over the internet is using XML messages (which makes it inter-operable)
This brings us to different type of web services, mainly divided into SOAP and RESTful.
A SOAP web services use the XML (which conforms the a specific protocol or xml schema which in other words referred as WSDL ). So a SOAP web servies puts certain rules/regulation on the way the messages are exchanged between the web services and their clients. The messages can be exchanged using any convenient protocol apart from HTTP.
Now in a RESTful scenario, you still exchange messages (xml/json etc) BUT there are no new additional specifications (I know WADL but its invented more for providing tooling support RESTful and has nothing to do the RESTful web services per se)
In RESTful, there are no new protocol definition (for exchanging messages). It uses already established norms of HTTP protocol which are passing parameters in URL as path elements and the HTTP methods to send data (namely GET/POST/PUT/DELETE).
Now coming on to your question of whether Servlets are restful web service are not, lets see what Servlets do
Accept the GET/POST request
Return an HTML (well generally) (which essentially is XML)
Now if a servlet is written in such a way, that it can be invoked by following URL
http://www.myrestwebservices/services/getstockquote/GOOG
This servlet
is mapped to the URL pattern /services/getstockquote
gets GOOG as input data in URL path, which it can parse, query some system to get the latest stock quote of Google.
Return the data as text/xml to the clients
Isn't this servlet satisfying the following basic requirements of a RESTful scenario ?
Use HTTP methods explicitly
Be stateless.
Expose directory structure-like URIs.
Transfer XML, JavaScript Object Notation (JSON), (text essentially)
So technically speaking, yes a Servlet is a RESTful web services, but that may not be enough for generic business requirement of a web services per se. So for a full blown RESTful web servies, we need a servlet (nevertheless) written specifically to address those basic business requirements.
Well you can possible design RESTful webservices with Servlet.
The Servlet helps you create HTTP response for a HTTP request. RESTful webservices seats on top of HTTP protocol so you can make a REST service with Servlet.
Any code (with any language etc) that is based on HTTP can be a restful web service as long as it conforms to the requirements of REST...
See: http://en.wikipedia.org/wiki/Representational_state_transfer
Everything is a Resource
All resources expose a standard interface GET, POST, PUT, DELETE
REST services are idempotent
Resources may link to other resources
Multiple representations
Stateless communication
See this post for details on the above
Your approach for such questions should be bottom up. Start with a definition of Service. Then define Web Service and then you can easily distinguish between what is a Web service and what is not. Generally, for such discussion, I attack it like this:
Any reusable piece of code which defines a contract for client is a service. A printer driver on your desktop is a service.
Any Service which can be used over the web ( over HTTP in text request/resposne ) is a Web Service.
A RESTful service adds more contraints in terms of VERB vs NOUN separation and concept of Resources.
How Servlets differ from REST is the absence of contract in Servlets and hence Servlets by themselves are not Services.
Nobody can stop a person who wants to implement RESTful Service using Servlets - but it is too low level for REST development in a world where frameworks exist to help ease development !!
ALL Web Restful services in Java world are written over Servlet which is the lower end implementation for handling HTTP. If the transport is not HTTP, it is a Service but not Web Service :)
The answer i think is fairly obvious so the question they gave you is a bit peculiar. Both SOAP-based and REST-full services use HTTP as transport mechanism, so in effect they are web services.
Their difference is that SOAP-based services are more strictly defined by a specification whereby REST-full services are more like an architectural style less constrained in their implementation.
Related
I know RESTful WS is an architecture all together, which is a new way of implementing Web Services over old fashioned JAX-RPC's.
In RESTful, we use #GET, #POST, etc to manage calls/develop resources. Same can be achieved using HTTP programming (both are stateless too).
But what are other core main uses or need for bringing/implementing RESTful? As everything we do in it, can be done using HTTP programming (in which we use same methods)?
The question is comparing different things. HTTP is a protocol, while REST is an architectural style. This is like asking what a house does that a brick doesn't. It doesn't make sense. HTTP can be a building block of a REST application.
REST is not about HTTP or any particular protocol. REST is about applying the successful design decisions of the Web itself to software development. The problem is terminology. 99.9% of the so called REST applications around the internet aren't really RESTful, because REST became a buzzword to refer to any HTTP API that isn't SOAP. Some REST advocates gave up on fighting for the proper usage of the term and now refer to REST applications as Hypermedia.
Like the Web, REST is intended for software development in the scale of decades. REST makes it easier to evolve your application without breaking clients. Think about how today you can still access websites that were created decades ago, and almost everything still works fine. If you're creating software that has long-term objectives in the scale of several years, then maybe REST is adequate for you. If that's not what you really need, then getting REST right is not important. Just use whatever works for you, and at this point I think nobody cares anymore if you call it REST.
The question is not "REST versus HTTP-Programing". REST is a higher concept on how to to create distributed web applications. HTTP is a concrete technology . REST defines some constraints which are considered as good practice.
HTTP is just a technology which is well suited to implement REST-Style services:
Addressability => in HTTP every resource can be addressed through a unique identifier (URI)
multiple Representations => every resource can have multiple representations (JSON, XML) - a HTTP-Request for instance can 'ask' for the right representation (via headers)
Common Interface => Instead of creating an application specific interface (Methodnames in SOAP) HTTP already provides an Interface: GET, PUT, POST, DELETE ...)
Stateless => HTTP-Requests are stateless by design
Hypermedia => The application state (client) is driven by examining the links contained in the representations
HTTP is a transfer protocol.
RESTful is a group of principles.
Basically a RESTful web service is a particular HTTP application that follow the following principles:
client server
stateless
cacheable
layered
This question already has answers here:
Servlet vs RESTful
(3 answers)
Closed 7 years ago.
What is the difference between implementing a RESTful web service and a plain HTTPServlet.
All GET/POST/DELETE/PUT are supported in Servlet as well as any REST API.
REST is really an architectural style used when designing an API on a server. HttpServlets can be a method of implementing a RESTful web service.
REST describes a style where HTTP verbs like GET/POST/DELETE/etc. are used in a predictable way to interact with resources on a server.
I'd recommend reading through the REST Wikipedia page for a good overview.
REST is an architectural pattern (abstract), while servlets are an implementation.
My 5 cents here :)
As for me - Servlets are just an abstraction over HTTP protocol.
It supports GET/PUT and so on because the Http Protocol defines these methods.
Restful web service on the other hand is an abstract notion that talks about the ideology of operation the resource, rather than particular implementation.
Its true that its very convenient to think about rest functionality in a context of HTTP protocol, but try to think about them as they're entirely different beasts. Restful web service is not something Java specific.
Technically if you're talking about Java, restful web service can be implemented with vanilla servlets, or one can use tools like Apache Wink or Jersey that define a convenient way of implementing rest services, but these are after all just tools.
BTW, Jersey (as I know, I don't know about others) is implemented on top of servlets.
Hope this helps
An HttpServlet responds to HTTP methods in a way that the programmer deems fit. A RESTful web service should be based on handling of entities. The CRUD should corresponds to HTTP method POST, GET, PUT and DELETE. Also the url should be defined according to a format, e.g. {server}/{entities}, {server}/{entities}/{id} etc.
As the name suggest the RESTful web service is a web service which is used to establish communication between 2 different server and hence helps in integration of web based application.web service uses HTTP protocol.
Whereas, HTTPServlet is a Servlet that support HTTP calls. The different methods in this all support HTTP protocol.
i'm new with web service programming and i want to create,using netbeans 6, a restful web service using Jersey over a Grizzly server and then a client javascript in order to use this web service through a browser. So i started learning more on restful web service and i read a lot of guide over the web, then i started learning more on grizzly and jersey by reading jersey user's guide http://jersey.java.net/nonav/documentation/latest/index.html. I succesfully follow the tutorial to create the helloword example resource. So i created all the resources needed for the job and tested successfully with the browser...but i'm still confused: in particular i want know how i can create a static homepage which can be used by the users to select what is the desired resource. Can you give me some tutorial or example?? Thanks to all!
(Moreover i want to learn more on grizzly server and creating jersey restful web service, can someone give me a useful guide or book??)
So, the key to understanding RESTful web services is to understand the HTTP protocol more thoroughly. That's what makes it easier than (and often preferable to) RPC style services epitomized by SOAP. When you pull down a static web page, for example, you can think of it as a limited "web service" which serves only GET requests. In order to make a static web page which "selects resources," you would only need to provide URLs to the resources in question, as long as they're accessed via GET, because that's the same HTTP method used for retrieving web pages (and therefore is the default method for web browsers). If you want to access other types of resources, such as sending POST requests, you can use a form; other than that (with PUT, DELETE, HEAD, OPTIONS, etc.) you'll want to use Javascript or a more programmatic API for accessing the HTTP resources.
There are many good books in this space, and I've found these particularly useful:
RESTful Web Services
RESTful Web Services Cookbook
RESTful Java with Jax-RS
SOA With REST
The first two approach REST in theory and practice; they are more about the concepts than specific technology. The third addresses the Java standard for RESTful services as defined in JSR 311, of which Jersey is the reference implementation.
The last is more of an "enterprisey" book, but it's been useful to me from the approach of designing a system of web services, as opposed to one-off service resources.
Regarding Grizzly you can take a look at Grizzly User's Guide, specifically Http Server framework chapter. If you have more questions don't hesitate to ask on Grizzly mailing lists.
I am building websites in spring MVC. as there are many spring projects , i wanted know what will be scenario when spring web Services is used for.
i mean what can be done with that. Do i really need it for ecommerce site
Your question is really about "web services". For a layman's explanation of what it is all about, read this Wikipedia article.
There are a number of related acronyms that get bandied about:
SOAP (Simple Object Access Protocol) is a protocol for sending requests to a service and getting back a response. The messages are encoded in XML, and send over HTTP.
WSDL (Web Services Description Language) is a service description language for SOAP-based services. It does things like specify what is in the messages, and how the messages are bound to services.
SOA (Service Oriented Architecture) is essentially a system architecture in which the system consists of lots of SOAP services (and others) described using WSDL.
(The proponents of SOA talk about "design principles", but in my cynical view is that this is just a repackaging / recasting of stuff that people have been doing for 20+ years under other names.)
Do i really need it for ecommerce site
Ask your customers. Ask the people whose systems your system will be interfacing with. Ask the vendors whose components you intend to embed in your system.
If you have to use WS then what extra facility it will give
If you have to use WS (e.g. because your site needs to talk to other services that require WS), then you have to. That is sufficient justification.
If you don't have to use WS, then you need to balance the advantages of using WSDL + SOAP against the advantages of some other approach to implementing your web APIs. An SOA expert will probably say use SOA; an AJAX expert will probably say otherwise. And there are other remote procedure call technologies around ... if you really need that kind of thing.
WSDL + SOAP certainly does have some advantages; e.g.
machine readable specifications for your web APIs,
possibility of validation of messages against XML schemas,
an ecosystem of existing WSDL services,
adoption in some sectors of IT.
But it has downsides also; e.g.
WSDL + SOAP have a significant learning curve compared to some alternatives,
XML is a heavy-weight encoding scheme - relatively expensive to parse,
SOAP only pretends to be type-safe (compared with say CORBA / IIOP),
SOAP is not usually used* in browser-based clients; JSON or plain XML are commonly used for AJAX apps,
many people think SOA is over-hyped and steer clear.
* However, it can be used; read these IBM DeveloperWorks Articles.
My advice (FWIW) if your system is primarily a website, doesn't need to talk to SOAP services, and doesn't need to provide a SOAP service API for others .... don't bother. You can always add SOAP service APIs later if you need to.
Spring Web Services is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.
More here : Spring Web Services
How to use Spring Web Service : Spring WS
If you don't know what Web Services are, you probably don't need them. Web Services are a way (speaking generally here) for one web application to talk to another. You can formulate a request as an xml document and send that xml to a web service, which is listening on a specific URL and port. The Web Service can then perform some action based on this document, and respond back with an XML document. It's commonly used as a means for integration between applications.
If you're building a simple e-commerce site, which does not integrate with other live web products, then likely you don't need Web Services. Spring Web Services is simply an API/library to make reading/writing web services easy.
This question already has answers here:
SOAP vs REST (differences)
(13 answers)
Closed 5 years ago.
For now I have a slight idea about the differences between SOAP and RESTful services.
My question is when I should use SOAP, and when I should use RESTful; which one is "better" when it comes to performance/speed or request handling?
I'm implementing it for the first time in RESTful (Java) and I want know more about it; I've dealt with SOAP before.
This is a follow-up question to this post.
REST is almost always going to be faster. The main advantage of SOAP is that it provides a mechanism for services to describe themselves to clients, and to advertise their existence.
REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve. However, the clients have to know what to send and what to expect.
In general, When you're publishing an API to the outside world that is either complex or likely to change, SOAP will be more useful. Other than that, REST is usually the better option.
REST vs. SOAP Web Services
I am seeing a lot of new web services are implemented using a REST
style architecture these days rather than a SOAP one. Lets step back a
second and explain what REST is.
What is a REST web service?
The acronym REST stands for representational state transfer, and this
basically means that each unique URL is a representation of some
object. You can get the contents of that object using an HTTP GET, to
delete it, you then might use a POST, PUT, or DELETE to modify the
object (in practice most of the services use a POST for this).
Who's using REST?
All of Yahoo's web services use REST, including Flickr and Delicious.
APIs use it, pubsub, bloglines, Technorati, and both eBay, and Amazon
have web services for both REST and SOAP.
Who's using SOAP?
Google seams to be consistent in implementing their web services to
use SOAP, with the exception of Blogger, which uses XML-RPC. You will
find SOAP web services in lots of enterprise software as well.
REST vs. SOAP
As you may have noticed the companies I mentioned that are using REST
APIs haven't been around for very long, and their APIs came out this
year mostly. So REST is definitely the trendy way to create a web
service, if creating web services could ever be trendy (lets face it
you use soap to wash, and you rest when your tired). The main
advantages of REST web services are:
Lightweight - not a lot of extra XML markup Human Readable Results
Easy to build - no toolkits required. SOAP also has some advantages:
Easy to consume - sometimes Rigid - type checking, adheres to a
contract Development tools For consuming web services, its sometimes a
toss up between which is easier. For instance Google's AdWords web
service is really hard to consume (in ColdFusion anyway), it uses SOAP
headers, and a number of other things that make it kind of difficult.
On the converse, Amazon's REST web service can sometimes be tricky to
parse because it can be highly nested, and the result schema can vary
quite a bit based on what you search for.
Whichever architecture you choose make sure its easy for developers
to access it, and well documented.
Freitag, P. (2005). "REST vs SOAP Web Services". Retrieved from http://www.petefreitag.com/item/431.cfm on June 13, 2010
SOAP
Simple Object Access Protocol (SOAP) is a standard, an XML language, defining a message architecture and message formats. It is used by Web services. It contains a description of the operations.
WSDL is an XML-based language for describing Web services and how to access them. It will run on SMTP, HTTP, FTP, etc. It requires middleware support and well-defined mechanism to define services like WSDL+XSD and WS-Policy.
SOAP will return XML based data
REST
Representational State Transfer (RESTful) web services. They are second-generation Web services.
RESTful web services communicate via HTTP rather than SOAP-based services and do not require XML messages or WSDL service-API definitions. For REST middleware is not required, only HTTP support is needed. It is a WADL standard, REST can return XML, plain text, JSON, HTML, etc.
REST is an architecture.
REST will give human-readable results.
REST is stateless.
REST services are easily cacheable.
SOAP is a protocol. It can run on top of JMS, FTP, and HTTP.
REST has no WSDL (Web Description Language) interface definition.
REST is over HTTP, but SOAP can be over any transport protocols such as HTTP, FTP, SMTP, JMS, etc.
REST stands for representational state transfer whereas SOAP stands for Simple Object Access Protocol.
SOAP defines its own security where as REST inherits security from the underlying transport.
SOAP does not support error handling, but REST has built-in error handling.
REST is lightweight and does not require XML parsing. REST can be consumed by any client, even a web browser with Ajax and JavaScript. REST consumes less bandwidth, it does not require a SOAP header for every message.
REST is useful over any protocol which provide a URI. Ignore point 5 for REST as mentioned below in the picture.
REST vs. SOAP
SOAP:
► SOAP is simple object access protocol that run on TCP/UDP/SMTP.
► SOAP read and write request response messages in XML format.
► SOAP uses interface in order to define the services.
► SOAP is more secure as it has its own security and well defined standards.
► SOAP follows RPC and Document style to define web services.
► SOAP uses SOAP-UI as client tools for testing.
REST
► REST is representational state transfer that uses underlying HTTP protocols.
► REST is stateless.
► REST is an architectural style that is used to describe and define web services.
► REST can read and write request response messages in JSON/XML/Plain HTML.
► REST uses URI for each resource that is used in web service.A resource can be image text method etc.
► REST uses set of verbs, like HTTP's GET, POST, PUT, DELETE.
► REST is easy to develop and easy to manage as compared to SOAP UI.
► REST has light-weight client tools or plugins that can easily be integrated inside a browser.
► REST services are cacheable.
Difference between REST and SOAP:
SOAP Web services:
If your application needs a guaranteed level of reliability and security then SOAP offers additional standards to ensure this type of operation.
If both sides (service provider and service consumer) have to agree on the exchange format then SOAP gives the rigid specifications for this type of interaction.
RestWeb services:
Totally stateless operations: for stateless CRUD (Create, Read, Update, and Delete) operations.
Caching situations: If the information needs to be cached.
SOAP web service always make a POST operation whereas using REST you can choose specific HTTP methods like GET, POST, PUT, and DELETE.
Example: to get an item using SOAP you should create a request XML, but in the case of REST you can just specify the item id in the URL itself.
REST is easier to use for the most part and is more flexible. Unlike SOAP, REST doesn’t have to use XML to provide the response. We can find REST-based Web services that output the data in the Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS) formats.
We can obtain the output we need in a form that’s easy to parse within the language we need for our application.REST is more efficient (use smaller message formats), fast and closer to other Web technologies in design philosophy.