We Keep Coding

Is there any use for WSDL file in REST or JSON web service? [duplicate]

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.

How to build configurable facade over set of RESTful services

It's time to ask question on StackOverflow because I did not find a good one in Google.
We have a legacy systems(2 in my case) that provide some functionality via RESTful web-services.
Now we are building a Java EE system that will consume RESTful services from that legacy systems.
Questiuon: how to build convenient facade API over mentioned RESTful web-services to use them easily in our Java EE app?
Are there some frameworks to easily consume a set of REST web-services and it can be XML-configured?

There is a number of options
The most "low level" - HTTP Client (http://hc.apache.org/httpclient-3.x/)
Something more abstract - RestEasy ClientRequest/ClientRespons (http://docs.jboss.org/resteasy/docs/1.2.GA/javadocs/org/jboss/resteasy/client/ClientRequest.html) there is a number of tutorials how to work with it
You might like it most due to XML config - Spring Framework RestTemplate support (see, for instance http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/client/RestTemplate.html), there is a number of tutorials in the web too.

Best practices to implement SAML in REST services

We were looking to use Apache CXF framework to implement REST services. We would like to provide federated access to the rest services via SAML. The identify provider will a rest service (back ended by a DB) that would accept a user/pass and return a SAML assertion.
What would be the best practice in achieving this?

Best practice is to conform to the SAML v2 Web Profile. But the problem there is that the Web Profile relies on sessions, typically managed by cookies. Sessions are a stateful artifact that are contrary to REST.
So, rather than using SAML, perhaps you should consider something like OAuth 2, which is a bit friendlier to HTTP and REST, since it can (by design) use the actual HTTP headers as part of its transaction and not rely on sessions.

If you are willing to be a little loose in your definition of "RESTful", you may want to look at this:
http://cxf.apache.org/fediz.html
This is CXF's implementation of the SAML standard.
Or, follow the directions here to do it with CXF without the Fediz plugin:
https://cwiki.apache.org/confluence/display/CXF20DOC/SAML+Web+SSO

what is spring web services used for

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.

Main differences between SOAP and RESTful web services in Java [duplicate]

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.