As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
A web service is a function that can be accessed by other programs over the web (Http). To clarify a bit, when you create a website in PHP that outputs HTML its target is the browser and by extension the human being reading the page in the browser. A web service is not targeted at humans but rather at other programs.
SOAP and REST are two ways of creating WebServices. Correct me if i
am wrong?
What are other ways i can create a WebService?
What does it mean fully RESTful web Application?
Correct
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network".
A fully RESTful service is one that adheres to all or the architectural constraints as layed out in Roy Fielding's thesis, Architectural Styles and the Design of Network-based Software Architectures. It's a long read and there are many interpretations. A good start would be to familiarise yourself with the Richardson Maturity Model. NOTE: Most Web Services that claim to be RESTful are only at level 2 in that model.
I think that to understand what is a fully RESTful service you have to understand the difference between RESTful services and standard Web Services. It's quite good exaplained in JEE6 Tutorial by Oracle:
NonRESTful WebServices (In Java as JAX-WS): Big web services use XML messages that
follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a
message architecture and message formats. Such systems often contain a machine-readable
description of the operations offered by the service, written in the Web Services Description
Language (WSDL), an XML language for defining interfaces syntactically.
The SOAP message format and the WSDL interface definition language have gained
widespread adoption. Many development tools, such as NetBeans IDE, can reduce the
complexity of developing web service applications.
A SOAP-based design must include the following elements.
■ A formal contract must be established to describe the interface that the web service offers.
WSDL can be used to describe the details of the contract, which may include messages,
operations, bindings, and the location of the web service. You may also process SOAP
messages in a JAX-WS service without publishing a WSDL.
■ The architecture must address complex nonfunctional requirements. Many web service
specifications address such requirements and establish a common vocabulary for them.
Examples include transactions, security, addressing, trust, coordination, and so on.
■ The architecture needs to handle asynchronous processing and invocation. In such cases,
the infrastructure provided by standards, such as Web Services Reliable Messaging
(WSRM), and APIs, such as JAX-WS, with their client-side asynchronous invocation
support, can be leveraged out of the box.
RESTful Web Services (In Java as JAX-RS)
In Java EE 6, JAX-RS provides the functionality for Representational State Transfer (RESTful)
web services. REST is well suited for basic, ad hoc integration scenarios. RESTful web services,
often better integrated with HTTP than SOAP-based services are, do not require XML messages
or WSDL service–API definitions.
Project Jersey is the production-ready reference implementation for the JAX-RS specification.
Jersey implements support for the annotations defined in the JAX-RS specification, making it
easy for developers to build RESTful web services with Java and the Java Virtual Machine
(JVM).
Types of Web Services
Because RESTful web services use existing well-known W3C and Internet Engineering Task
Force (IETF) standards (HTTP, XML, URI, MIME) and have a lightweight infrastructure that
allows services to be built with minimal tooling, developing RESTful web services is inexpensive
and thus has a very low barrier for adoption. You can use a development tool such as NetBeans
IDE to further reduce the complexity of developing RESTful web services.
A RESTful design may be appropriate when the following conditions are met.
■ The web services are completely stateless. A good test is to consider whether the interaction
can survive a restart of the server.
■ A caching infrastructure can be leveraged for performance. If the data that the web service
returns is not dynamically generated and can be cached, the caching infrastructure that web
servers and other intermediaries inherently provide can be leveraged to improve
performance. However, the developer must take care because such caches are limited to the
HTTP GET method for most servers.
■ The service producer and service consumer have a mutual understanding of the context and
content being passed along. Because there is no formal way to describe the web services
interface, both parties must agree out of band on the schemas that describe the data being
exchanged and on ways to process it meaningfully. In the real world, most commercial
applications that expose services as RESTful implementations also distribute so-called
value-added toolkits that describe the interfaces to developers in popular programming
languages.
■ Bandwidth is particularly important and needs to be limited. REST is particularly useful for
limited-profile devices, such as PDAs and mobile phones, for which the overhead of headers
and additional layers of SOAP elements on the XML payload must be restricted.
■ Web service delivery or aggregation into existing web sites can be enabled easily with a
RESTful style. Developers can use such technologies as JAX-RS and Asynchronous
JavaScript with XML (AJAX) and such toolkits as Direct Web Remoting (DWR) to consume
the services in their web applications. Rather than starting from scratch, services can be
exposed with XML and consumed by HTML pages without significantly refactoring the
existing web site architecture. Existing developers will be more productive because they are
adding to something they are already familiar with rather than having to start from scratch
with new technology.
Deciding Which Type of Web Service to Use
Basically, you would want to use RESTful web services for integration over the web and use big
web services in enterprise application integration scenarios that have advanced quality of
service (QoS) requirements.
■ WebServices: addresses advanced QoS requirements commonly occurring in enterprise
computing. [..]
■ RESTfull: makes it easier to write web applications that apply some or all of the constraints of the REST style to induce desirable properties in the application, such as loose coupling
(evolving the server is easier without breaking existing clients), scalability (start small and
grow), and architectural simplicity (use off-the-shelf components, such as proxies or HTTP
routers). You would choose to use JAX-RS for your web application because it is easier for
many types of clients to consume RESTful web services while enabling the server side to
evolve and scale. Clients can choose to consume some or all aspects of the service and mash
it up with other web-based services.
Related
This question already has answers here:
RESTful Services - WSDL Equivalent
(8 answers)
Closed 3 years ago.
I am implementing a web service and I have implemented both a REST and SOAP version to see which suited my needs.I have decided to choose REST because of its simplicity and that I will probably be developing an iPhone app to consume it. My question is simple really, is it possible to create a WSDL or WADL for my REST service and is it necessary?
Thanks
With a good RESTful service, it's not necessary to generate WADL (let alone the much-less-well-fitting WSDL) for it because it will self-describe. By “self-describe” I specifically mean that it will deliver documents describing all the (relevant) resources published by the service, and that using a standard HTTP OPTIONS request on any of these will produce basic information about how to interact. The only real benefit to using WADL is that it allows the caller to discover the schemas for the complex documents it needs to work with ahead of time; REST itself provides no help there (and some RESTians believe that doing such things is counter-productive, which I'm not sure I agree with).
Of course, that doesn't capture the deeper interaction patterns, but neither do the vast majority of WSDL descriptions of services so no change there.
For the record, I use Apache CXF to create RESTful services (using JAX-RS) and that publishes WADL for them.
The W3C has made a formal recommendation for a REST documentation standard based on [WSDL 2.0][3]. Here is a quote from the IBM article:
The term Web services is typically associated with operation- or
action-based services using SOAP and the WS* standards, such as
WS-Addressing and WS-Security. The term REST Web services generally
refers to a resource-based Web services architecture that uses HTTP
and XML. Each of these architectural Web service styles has its place,
but until recently, the WSDL standard didn't equally support both
styles. The WSDL 1.1 HTTP binding was inadequate to describe
communications with HTTP and XML, so there was no way to formally
describe REST Web services with WSDL. The publication of WSDL 2.0,
which was designed with REST Web services in mind, as a World Wide Web
Consortium (W3C) recommendation means there is now a language to
describe REST Web services.
As #GiuliaDiFederico said, "of course it's possible" (with WSDL2), showing a good source link about how to do. #DonalFellows, by other hand, does not encouraged the use of WSDL...
I think the use of WSDL is a question of
FORMALIZATION LEVEL: with WSDL you can express more formally all relevant details of your webservice.
STABILITY LEVEL: if you need long term contracts, and avoid risks of changes in the enviroment where your webservice is exposed, WSDL helps to mantain stability.
NEED FOR STANDARDS: if customers prefer webservices that can be said "standard compliant", use standards. The only one is W3C, and W3C requires XML, SOAP and WSDL.
RestDoc tries to create a simple documentation framework for REST resources.
A browser is available via restdoc-renderer.
It also offers Java annotations to enable on-the-fly creation of RestDoc documetnation. Implementations are available for Jersey 1.x and JAX-RS 2.0.
Of course it's possible, but for answer if it is necessary or not, you didn't provide enough info.
I suggest you to take a look on the ibm's developerworks site that provide an interesting article on subject
Strictly, with WSDL 1.0 you can' t, but with WSDL2 you can, because was developed for accept this kind of demand,
"... WSDL 2.0 in a WS-I profile that addressed the requirements
for REST style Web services. The addition of GET in SOAP 1.2 and several
additions in WSDL 2.0 such as operation safety, the ability to describe
messages that refer to other Web services, and the improved HTTP binding
now make it possible to describe REST style Web services.", Arthur Ryman.
I think WSDL is not appropriate for REST and WADL is not necessary. HTTP exposes already what WADL could describe in a separate file. For example the "Allow" header returns allowed HTTP method, and Content Negotiation is for choosing the right format.
WADL is not necessary. But, If Client side code is already present in an application and you want to make a new rest call then it is good practice that you use wadl for generating the client side java stub(POJO). By this way, client side POJOs will be in sync with service side POJOs. For example, If you are replacing EJB/SOAP service call with Rest service call in an existing application then It is very safe and good practice to use WADL.
You can generate client side java stubs from WADL by using wadl2java maven plugin.
We are evaluating one design for educational activity. We would like to create complete backend (which handles business logic) in form of RESTful web services.
These services can be used by various apps. Is it good idea to call these web services from Struts 2 framework? I read couple of docs, and people discourage it.
We would love to go with Struts 2 as team is quite strong on it. But if its bad approach, we may consider for other options.
If you want to leverage development on presentation layer between client-side and server-side (this is where Struts2) then you can utilize web services using a web services client API. At this point these web services can be used as data resources.
If you want to stay only on client-side then you don't need any server-side framework for the frontend development.
Note that The introduction to Struts2 and RESTful applications you have posted in comment introduces an alternative way instead of web services for creating backend in a form of RESTful API using Struts2 framework.
Using Struts2 for the REST instead of web services could be a solution for RAD (Rapid Application Development). Because web services are very complicated technology that used in upper high level architectures and using some alternative resource APIs might be cost effective.
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.
I have developed two java web services; one is SOAP based and the second one REST. Now I have to ask some clients (they can be either java/non java clients) to use my web services. Now what information do I need to pass to the clients to use my web service?
If SOAP, what should I share to clients to use my web service?
If REST, what should I share to clients to use my web service?
With SOAP, you should share the WSDL document that describes the service. This should be enough, but often isn't; the most common missing things are what type of security is required and what interaction patterns (i.e., how to string the methods together) should be used. Theoretically, WSDL can describe these things. Practically, you never see them in the wild. In fact, you're probably better off doing the interaction patterns by just documenting them properly in a human-readable document.
With REST, the ideal is often regarded as being just sharing the URL to the root page of the service, as the service should be self-describing to an extent whereby clients can find out what to do by just following links. This is the core of the HATEOAS principle. In practice, it is much more complex than that. Many JAX-RS implementations can publish service descriptions via a WADL document, which can help. The typical security models used with REST are more discoverable than with SOAP, but are still rather opaque even so, and interaction patterns remain problematic (prodding random stuff at a service in the hope that it works sucks, whether you're doing SOAP or REST or whatever).
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.