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...)
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 want to intercept/sniff incoming HTTP request and filter/modify their contents (before they reach the application).
"Fiddler" seems to have this functionality, but for the sake of integration and portability I would rather have some library in Java/C to do this. Like JPCAP, for example. It intercepts IP packets, but, as stated, I need to intercept the -higher level- HTTP requests.
Furthermore, how can SSL encrypted (HTTPS) requests be read/modified in the same way?
Thanks in advance.
Have you tried Servlet Filters?
They wrap the HTTP request and so can modify the request before it gets to the servlet, and can modify the response as well. They can (and are) used to wrap third-party servlets and JSPs.
Because they are in the servlet container, you have secure, unencrypted access to both the request and response.
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.
I have a Spring-MVC webapp (3.0.5-RELEASE) which needs to access JSON webservices from another webapp on a different sub-domain (from the client/browser via AJAX).
I've solved this in the past by either:
writing a simple controller that proxies the requests, using Apache Commons HttpClient to handle the requests. Thus overcoming the cross-site/cross-origin request security limitations of most browsers
implementing a JSONP service on the server side (when calling our own JSON services) - not always possible
In the case where JSONP is not possible, is there a better way of doing (1.)?
and/or
Is there a library that will handle this for me? So I don't have to write all the HttpClient code myself - its not a lot of code, but I wonder if I'm (badly) re-inventing the wheel.
I have often had to consume third party web services (API), and as you mentioned, JSONP is not always an option. This is how I go about designing:
If the API is user centric, it has to provide a jsonp interface and that's what I will use. User centric means that you cannot perceive any reason to call the API, do some computations with the response, may be call one of your ajax services and then combine the response and show the user.
If my use case includes calling the API, and then acting on the response, like calling additional services from my application, combining the data and then showing it to the user, I would prefer not doing this in the browser. I would instead use RestTemplate and make backend api calls to the service. In which case there are no cross domain restrictions.
The only case where using a Server Proxy to bypass jsonp is when you are creating a Product that allows people to build custom plugins, plugins which are hosted on your page, but need to make Ajax calls to the app developers servers. This is a very involved case! (As as example look at how Apigee creates Public Facing REST API around your existing urls, or how Zendesk allows you to develop apps)
Hope this helps.
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).