Asked in the interview:
What is the difference between HTTP servlet and SOAP over HTTP?
What the advantages and disadvantages of both?
In which case would use which?
I would ask if he / she could repeat the question, because it doesn't make much sense in my view. You could very well create a HTTP Servlet that returns SOAP via HTTP.
I guess you would have to explain first what SOAP is, and what a Servlet is.
You didn't mention your background about the APIs mentioned.
In an interview they probably want to hear that a servlet processes a http-request and responses with a http-response as a soap does. The difference is that a soap request contains xml data (header and payload) which has to be parsed in a different way (usually with a framework like Xfire or Axis among others).
Related
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
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.
If I have some APIs using SOAP, how do I know if the methods requires a GET, POST or other?
Also, What are the consequence (not even sure it would work) if I use a GET for a SOAP web service requiring a POST? or vice-versa?
Thanks, I'm still trying to get a good understanding on how to consume web services. I got some working with simple API's, but really having problem using a web service that returns is used to download files. Thanks again.
HTTP GET requests generally do not have a content part which how the SOAP message is transmitted to the server. This is why POST is used.
Specifically from RFC 2616 Section 4.3. Emphasis mine.
A message-body MUST NOT be included in a request if the specification
of the request method (section 5.1.1) does not allow sending an
entity-body in requests. A server SHOULD read and forward a
message-body on any request; if the request method does not include
defined semantics for an entity-body, then the message-body SHOULD be
ignored when handling the request.
EDIT:
As of SOAP 1.2 it is possible to use HTTP GET method and get a SOAP response back. I recommend reading the SOAP 1.2 primer Section 4.1 for details about which HTTP methods are appropriate in what situations.
One desktop application needs to get some services from server.
For example sending some parameters and receiving some result.
Imagine implementing a solution by Java Servlets, in a way that the app sends the parameters to the servlet (POST) and receives the result in XML.
Does this approach have any security issue in compare with web-services (Soap / Restful) ?
Thanks and sorry if the question is a bit general.
I don't think so. But personally I would still go over REST, mainly because it would be easier to maintain and update if needed. Also probably easier to test and implement.
As long as your solution has suitable authentication (username/password) and takes place over SSL, it's no less secure than Web Services/SOAP. And indeed you might find it a simpler solution to implement.
The security issue is the same for both solutions because it's http but I won't do the post thing because it's not structured properly, meaning it's client dependent and not using a standard. If you don't like XML, you can try JSON.
Servlets are one way of handling requests/responses from a web client i.e. a client makes a request, server finds the appropriate servlet which can handle the request and generate the response which is then forwarded to the client.
Could someone please tell me ways of handling requests/responses other than Servlets. I know CGI is another option, what else can be used?
CGI is a poor choice for implementing HTTP protocol on the server-side. You can write the server manually (by opening a ServetSocket, parsing HTTP reauest headers and responding according to the spec, however this approach is very tedious and error-prone.
If you want to handle web client requests, servlets are basically the only reasonable choice. Of course there are tons of wrapping technologies and frameworks (web, SOAP, REST, AJAX...)