We have a server process that replies to HTTP POST only.
The framework that I use, gsoap, provides an HTTP GET plugin.
I would like to ask what is the purpose of http GET in soap. What are the benefits?
Could you please share your experience, if any?
It represents different message exchange pattern. When you send POST you are issuing SOAP request and receiving SOAP response - that is called request-response message exchange pattern. When using GET you are calling "resource" by URI and including Accept HTTP header to request SOAP response - that is called response message exchange pattern.
These two patterns are used with HTTP binding defined in SOAP 1.2 (not every API supports this binding). Each message exchange pattern has its own purpose:
Response message exchange pattern is only for data retrieval. It should never change any data on the server.
Request/response message exchange pattern is for both retrieval and data modification on the server.
The benefit of HTTP GET can be anything related to differences between GET request and POST request. For example responses to HTTP GET requests can be cached on HTTP proxies.
Related
I will be happy to get advice from more experienced developers about adding Web Sockets into my HTTP-based project.
That’s the thing. I have developed the REST API based service. Everything works well enough, but… In some special cases my server needs a long time to serve client requests. It may be from 1 minute to several hours (and even days)! I implement some not-so-good algorithm to address this issue:
Client sends HTTP request
Server replies about registering request
Client starts sending HTTP requests to get necessary data (if response does not have needed information the client sends another request and so on)
That is all in a nutshell.
And it seems to be a bad scenario and I am trying to integrate web sockets for adding duplex-channels in this architecture. I hope that my API will be able to send info about updated data as soon as possible without the necessity of many requests from the client.
But I am a bit confused in choosing one of two ways to use web socket (WS).
Variant A.
The server only tells the client via WS that data is ready. And the client gets data by standard request-response HTTP method from REST API.
Variant B.
The server sends all data to the client via WS without HTTP at all.
What variant is more suitable? Or maybe some other variants?
I do not want to remove HTTP at all. I just try to implement WS for a particular kind of end-points.
Variant A would be more suitable and easy to implement. You can send message to the client after the data is ready, and he can then send request for the data. It will be like a simple chat websocket, and will serve your purpose.
Which HTTP Method is used to send SOAP messages?
I guess, if you are working at the servlet level,you could define the HTTP method(would there still be restrictions?).
But if all that is hidden, and I'm using a simple JAX WS webservice, which HTTP method would(should??) the request and response messages have?
I think JAX-WS and most other implementations use post for transmitting requests
you can verify it by capturing the request in TCP IP monitor
As I understand RESTful webservices use whole power of http, suffice to say all that rest need is http, but in the same time rest!=http. CRUD provides ability to do any action with API resourses, for example we send http request, this request has header for aunthefication, name of method (for example put), and json in body for updating. How this proces is running via SOAP? SOAP uses XML, but how this XML is delivered to API?
SOAP is based on XML and it conveys that messages are delivered in a SOAP envelope that has a header and a body.
When a SOAP message (be it a request or response) is delivered over HTTP you will have the whole envelope put in the HTTP body.
If the implementation is proper, in the HTTP header, in Content-Type you will have application/soap+xml.
Also in SOAP 1.1 you might have the SOAPAction header, which is not mandatory and is discussed in detail in this article.
See this article for sample raw SOAP request and response. Here is an intro to SOAP that you might also find helpful.
Hope this helps! Good luck.
The concept of Asynchronous Web Service is a web service where the client does not have to wait to receive a response from the server. in AJAX this is implemented by having a callback function to process the response. So the server indeed still sends the response to the client.
Is it possible to have an Asynchronous Web Service without response? Is there any platform that provide this?
Thank you.
I have done asynch web services in the past. They are very useful. YOu do not need a detailed response but you at least need an HTTP response, like 200 OK. If the client that makes the request provides some sort of ID or key for that request, then the client can use the same ID/key to later on query for the result/response of the request.
As far as frameworks that provide this, I do not know of any. In the past I would just have a shared memory store, like Memcache, to store the state and result of the request. As long as the state is shared across all nodes, any node can then process the call back request.
EDIT: Providing a key in the request can be done in either REST or SOAP environment. HTTP provides multiple places where a key can be communicated.
GET query param (REST)
HTTP header (SOAP/REST)
Added to the message body of a POST request. This can be done through two ways.
param in the message body (REST)
variable or attribute in serialized object (SOAP/REST))
I am just getting started with SOAP web services and stumbled across WS-Addressing.
I have read the Wikipedia page, but I'm having a hard time understanding just what the point of WS-Addressing is.
According to Wikipedia and various sources on the web, WS-Addressing allows to put "addressing information" or "routing information" into the header of a SOAP request.
Why is this useful? If I send a request via HTTP (or even via SMTP or UDP), then the address I send to is the address of the server which will process my request, and the server can simply reply by the same channel. So why is addressing/routing information needed?
I'd be particularly interested in some real-world (more or less) example where WS-Addressing is helpful.
I've found WS-Addressing particularly useful in situations where the SOAP response can't be served immediately. Either the resources to form the response are not available right away or the result itself takes a long time to be generated.
That can happen when your business process involves "a human touch" for example (processes like the ones WS-HumanTask is targeting). You can stick web services in front of your business, but sometimes business takes time. It might be a subscription that must be manually verified, something to be approved, whatever, but it takes days to do it. Are you going to keep the connection opened all that time? Are you going to do nothing else than wait for the response? No! That is inefficient.
What you need is a notification process. The client makes a requests but does not wait for the response. It instead instructs the server where to send the response by use of a "reply to" address. Once the response is available, the server connects to that address and sends the response.
And voila... asynchronous interactions between web services, decoupling the lifetime of the communication process from the lifetime of the HTTP connection. Very useful...
But wait... HTTP connection? Why should I care about that? What if I want the response sent back on another type of protocol? (which SOAP kindly provides as it is not tied to any protocol).
With normal request/response flow, the response comes on the same channel as the request 'cose it's a connection you know.... So for example you have a HTTP connection... that means HTTP in and HTTP out.
But with WS-Addressing you are not tied to that. You can demand the response on another type of channel. Request comes on HTTP for example, but you can instruct the server to send the response back over SMTP, for example.
In this way WS-Addressing defines standard ways
to route a message over multiple transports. As the wiki page is saying:
instead of relying on network-level transport to convey routing information,
a message utilizing WS-Addressing may contain its own dispatch metadata in a standardized SOAP header.
and as for your observation:
and the server can simply reply by the same channel
... what works for some, might not work for others, and for others we have WS-Addressing :D.