We Keep Coding

Which is best/performance putting wrapper top of SOAP service or creating new REST full service?

All services are running in SOAP. for now they client asking us to provide a REST service.
I have two options
Write a wrapper for existing SOAP services to provide REST full services
Brand new REST full service.
Which is better (in performance perspective)?

A single service usually has better performance than a service and a proxy (wrapper).
However SOAP and REST (with JSON) services are approximately equal in performance, you'll come to see that in parsing/serializing XML and JSON to objects representations (with jackson or JAXB), the object creation is the most demanding part, not reading JSON or XML format. The overall impact on performance is probably lower than 5 percent - a single core can usually top 50 mb/s in parse/serialize capacity.
The above also implies that if you already have a very optimized SOAP backend, probably going with the proxy is the right choice.
Moving from SOAP to REST you should use a tool like swagger (OpenAPI) to define the service in as much detail as the SOAP service. Note that REST services also can use XML, but probably that is not what your client is expecting.

Definitely Writing a new Rest web service would be the better choice because
Rest is light weight due to statelesness(due to HTTP protocol).No state is maintained.hence keep ur resources free.
You don't require a schema as you need for soap webservice.Thus serializing and deserializing is also not required.Thus makes performance far better
Testing a rest service would be easy for you.
Even rest is supported to develop an App on the based of REST API you have developed if u require in future.
Rest supports multiple data excahnge formats for ex : json,text etc.
Rest can be easily integrated with high-end frameworks like Spring etc.
You may use better documentation for your service via Swagger for Rest to keep knowledge about your service for business understanding.

Soap webservice request vs HTTP POST request?

I am coming from servlet/web application world and started learning web services(SOAP based). I have gone through some of the webservice
tutorials. I am trying to draw the parallel between normal http request and webservice request. Here are my observations ;-
1)Both are HTTP request. Webservice is a also post request which contains soap envelope as request body. Soap envelope
is just a normal xml which contains the data
2)java Stub internally marshal the XML , creates HTTP request and send it to consumer
3)Servlet at consumer side intercpets that request and unrmashal it to java object and send it to corresponding service.
Is my observation correct ? I know there may be other complexities but i tried to put the comparison in simple manner.

Your assumptions are generally correct. Yet, the subtelties can lead to huge differences.
Claim 1 : both are HTTP.
SOAP is generally used with an HTTP "binding". Yet it does not have to be that way. SOAP is designed to be fairly transport agnostic. It is not uncommon to have SOAP being used over JMS (although one might consider this an overuse of JMS, and an over architected protocol), it is certainly in production in many places. Rarely seen are SOAP/SMTP or SOAP/TCP without HTTP, but these exist too.
Webservice is a also post request which contains soap envelope as request body
A SOAP call over HTTP is a POST request. It may not be of content-type xml, though, as some variants such as SwA (SOAP with attachments) or XOP+MTOM variants may produce HTTP payloads that are MIME/Multipart (the first part of which is the SOAP Enveloppe in its pure XML form).
This use cas is most common when on is to send large binary content over a SOAP Call, and for which binary encoding may add a large weight to the request (base64 is a 1.3x factor in weight).
java Stub internally marshal the XML, creates HTTP request and send it to consumer
That is the usual way it is done, Axis framework and JAXWS frameworks work primarily this way.
The older SAAJ API, a standard EE API, requires you to build your SOAP Message by hand, using the DOM APIs, (see SOAPMessageFactory), and then send it.
If you look at Spring WS, you'll have something close to your claim, but where each part is fairly exposed and in your control (you may elect to build certain calls with a DOM Api, others by using JAXB marshalling, ...).
3)Servlet at consumer side intercpets that request and unrmashal it to java object and send it to corresponding service
Again, this is how things generaly work. But you can also have an implementation that works outside a servlet container. (See Endpoint Service API in JAX WS).

Your assumptions are right:-
Yes, Servlet request and Web service request both are normal HTTP request and yes, SOAP web service internally use HTTP POST.
Yes,java internally marshal the XML. Also, at client end one java web service client(may be a wrapped in servlet) un-marshal it. A SOAP message or SOAP type web service has many characteristics like:-
SOAP message mostly send data using XML format. XMLs are technology independent. So, SOAP can interact with two heterogeneous web applications built in two separate technologies and exchange data using XML.
SOAP web services send XML using HTTP protocol. Data are sent wrapped in an XML using the payload of HTTP.
SOAP web services can be secured. For an example, all the payment related transactions using credit card and bank info are done using secured SOAP web services.
A SOAP web service accepts XML in request and returns XML in response. In case of errors this return XMLs can also contain SOAP faults. SOAP faults contain the description of error and an error code.
Web services can carry attachment document also like PDF, Word etc. with its XML payload. Java provides separate API for this type of web services. There is an API available in java called SAAJ to accomplish this.

I think that you can find a very good response in this blog post by Ben Klopfer.
Mainly the difference between XML/SOAP vs HTTP/REST is that the former is most response verbose while the latter is lighter.
But this is not the only aspect you have to take into account.
REST represents the state of the resource and is a little bit easier to use and to understand, and always remember that it comes afterwards compared to SOAP.
In addition SOAP it is not limited to using HTTP/HTTPS, but can be also used with other transports like SMTP, JMS, etc.
Resuming the post reminds you:
Use SOAP when:
All you need is simple operations, like read only methods
Implementing a one-way or one-object service for something like data exchange or transfer
You want finer control over the specific transport of data, or can’t always use HTTP
Rigid specifications need to be enforced on incoming requests, and you want to minimize additional documentation needed for use
You can rely on client ability to parse XML, or more preferably SOAP itself
You need built-in error handling when things go wrong with requests
Use REST when:
Operations are complex, like create/read/update/delete on objects
Implementing a multi-faceted service for a variety of different objects
You want to easily and quickly target a variety of consumer end user devices as clients
Requests are generally stateless, like call and response compared to a conversation
Your clients may have limited bandwidth or processing power
You can leave it up to the client to get their requests correct and to deal with problems

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.

Exposing SOAP endpoint in java for file Upload

I am new to Java SOAP web services. My questions are-
1) How can i expose and endpoint with SOAP, does WSDL definition always required? What is the content of that WSDL?
2) How my web service will know that it has to except a byte array? In REST, it was easy to get a file submitted using Multipart
3) What is the process of writing a SOAP server, the configurations? For REST using SPRING, it is declaring the servletTransport Beans in serverContext.xml and in web.xml give the 'servlet mapping'
4) Also, i need to know the scenarios where one cannot use REST web service
5) In SO, i read REST and SOAP are not mutually exclusive. A RESTful architecture may use HTTP or SOAP as the underlying communication protocol. How?

1) An endpoint using SOAP does not require a WSDL to operate but it is almost always there as it is very tightly coupled to the webservice. The WSDL contains a description of what the service looks like so basically which input and output parameters there are, their types etc. Actually exposing the endpoint is usually the task of the server so it will depend on what software you are running.
2) In SOAP you can use Multipart as well (google for XOP+MTOM) but unless you are talking really big files, you will probably use a base64 encoded string for byte[]. Depending on the framework this is not really your concern as the framework will see that you are trying to get a byte[] and will generate the base64 string automatically.
3) Don't know about spring, but for Java EE, the spec is JAX-WS. It is almost as easy as a JAX-RS (rest) service but there are a few additional things to keep in mind.
4) REST is easier than SOAP, but SOAP has the massive advantage that there is a WSDL. This allows client generation which reduces development time. REST has WADL but it's not there yet. For this reason SOAP is actually pretty much the de facto standard for business-level webservices.
5) REST is always HTTP as it basically reuses the entire HTTP "stack" (e.g. http authentication etc). SOAP however can run on anything (e.g. JMS, HTTP,...) though in practice people almost only use it on HTTP. However because it can not rely on a fixed protocol, it has reinvented every wheel. Whereas REST reuses HTTP authentication, SOAP has a spec to follow (WS-Security). There are a number of WS-* standards.

Service details in case of Java REST web services

I am new to web services in Java.
In SOAP web services, we have wsdl that tells us about the services like the operations etc. but in REST, we don't get wsdl.
So, my question is if someone wants to know the service details, then how that can be found in case of REST web services.

SOAP introduced WSDL to describe services, which can automatically be discovered and integrated with a mechanisms like UDDI. In reality SOAP is used just as hardcoded RPCs. If you use REST, many details like exceptionhandling, operation types, idempotency are handled using well known HTTP mechanisms. The only thing you need to know is the payload encoding. If you use XML, you may use XSDs to describe the services, if you use JSON you need to handle this on your own (its a lot simpler). The structure of your URLs should be designed so its intuitive enough, to be described in a one paged readme file.
To cut a long answer short: WebServices were so complicated you need a lot of boilerplating, REST services should be so simple, that a developr does not have to redefine and redocument the basics.

With REST there is no single established way to achieve this yet, however there are couple of options emerging:
Swagger http://swagger.wordnik.com/ - Inspects annotations in your source code (supports web frameworks JAX-RS annotations, Spring annotatins, Play2) and generates a JSON document describing your APIs. This JSON document can be displayed as an interactive web page as end user documentation using swagger-ui.
Json Home https://datatracker.ietf.org/doc/html/draft-nottingham-json-home-02 - Specification for a JSON document that describes your RESTful APIs
WADL http://en.wikipedia.org/wiki/Web_Application_Description_Language