Can somebody explain in a simple manner about what exactly happens with http and soap in web services.
I was going through http://vijaybalajithecitizen.blogspot.com/2008/11/aspnet-web-services-interview-questions.html
,it describes the soap but what about http, what are the relationship between them
When I call a webmethod from a asp.net application , is it a soap/http call...how does it return value.
How to detect if it is a soap/http call?
HTTP is the transport mechanism, SOAP is the payload protocol. SOAP can be transferred over other protocols, but HTTP is the most widely used. This is very similar to HTML and HTTP. HTTP is the transport, and HTML is the payload. You could also email an HTML file, which means it's no longer using HTTP.
When you call a webmethod (or any other webservice), it is a "SOAP over HTTP" call. HTTP includes a Content-Type header which is set to "soap+xml". That lets the server know what kind of payload is contained, and how to parse it. I'm not actually sure that ASP.NET webmethods look at that, though. It could just try to parse the HTTP request as SOAP, and error if it doesn't parse. You'd usually only check the Content-Type if you were able to support multiple formats on the same URL.
Values are returned as SOAP formatted messages in the HTTP response. So, instead of sending HTML back, the server sends an XML document in the SOAP format.
HTTP is a transport used to carry SOAP formatted payloads. You can also use TCP to transport SOAP as well, or whatever else might strike your fancy. HTTP is, obviously, the most common transport for the SOAP payload because these things were built for web-based RPC.
Related
Just a quick question, and probably a stupid one.
But usually when a client connects to an http server, the server sends them the header and the html, correct?
I'm packet sniffing a realtime-chat, and attempting to reverse engineer a plain text protocol, and it's connected to a http server. This is why I ask, for verification.
Basically, this is correct. Anyways, you have to differentiate between for example GET and POST Requests.
While POST Requests normally have a "real" body with information that they are delivering to the Server, the body of GET Requests is empty for most of the time.
For the responses, your Claim is correct. The Header is sent to tell how big the response is, which MIME Type is used, etc.
RPC protocol uses TCP as an underlying protocol and HTTP again uses TCP as an underlying protocol. So why is HTTP is widely accepted?
Why does SOAP use HTTP as an underlying protocol - why not RPC?
Remote Procedure Calls (RPC) is not a protocol, it's a principle that is also used in SOAP.
SOAP is an application protocol that uses HTTP for transport (so it won't have to think about encoding, message boundaries and so on). One of the reasons to use SOAP over HTTP is that for HTTP you usually don't need firewall rules and that the HTTP infrastructure is mature and commonly rolled out.
RPC does not require HTTP. Basically, RPC describes any mechanism that is suitable to invoke some piece of code remotely. The transport mechanism used to perform the RPC could be SOAP over HTTP. It could also be a REST call returning some JSON data over HTTP.
SOAP can also be used via Mails, and AFAIK (not sure here) the BizTalk Server should support this scenario. But even something exotical like trying SOAP over Avian Carriers can also be considered an RPC, although the latency of the latter may not be sufficient for real-world applications.
Think of an RPC as sending somehow some kind of message to a destination, in order to initiate a specific action and (optionally) getting some information back after the action has been completed. What prticular technology you choose to transmit these messages does not really matter.
I asked this question a few days ago, and I didn't get a lot of activity on it. And it got me thinking that perhaps this was because my question was nonsensical.
My understanding of http is that a client (typical a browser) sends a request (get) to a server, in my case IIS. Part of this request is the accept-encoding header, which indicates to the server what type of encoding the client would like the resource returned in. Typically this could include gZip. And if the server is set up correctly it will return the resource requested in the requested encoding.
The response will include a Content-Encoding header indicating what compression has been applied to the resource. Also included in the response is the Content-Type header which indicates the mime type of the resource. So if the response includes both Content-Type : application/json and Content-Encoding: gzip, the client knows that resource is json that is has been compressed using gzip.
Now the scenario I am facing is that I am developing a web service for clients that are not browsers but mobile devices, and that instead of requesting resources, these devices will be posting data to the service to handle.
So i have implemented a Restfull service that accepts post request with json in the body. And my clients send their post requests with Content-Type:Application/json. But some of my clients have requested that they want to compress their request to speed up transmission. But my understanding is the there is no way to indicate in a request that the body of the request has been encoded using gZip.
That is to say there is no content-Encoding header for requests, only responses.
Is this the case?
Is it incorrect usage of http to attempt to compress requests?
According to another answer here on SO, it is within the HTTP standard to have a Content-Encoding header on the request and send the entity deflated.
It seems that no server automatically inflates the data for you, though, so you'll have to write the server-side code yourself (check the request header and act accordingly).
I'm writing a web server, and I'd like to know what HTTP request headers (sent by the client) are the most common and thus that I should focus on implementing.
Right now, I only support Accept and Host.
Not sure on your scope but since you are interested in serving web browsers, you should have a look into the RFC (HTTP 1.1)
Read about what the server MUST process
The Cookie header might be a good idea, as would the Content-Length header; without Content-Length you won't be able to handle POST and PUT requests properly.
Also, can you SEND any header back? (return headers) when you run a web server?
Or, are headers limited?
Web pages are retrieved using the HTTP protocol. HTTP is text-based. Both, a client requesting and a server responding within a HTTP communication can add custom headers to the HTTP messages. Its up to the communicating parties how to process these. I would assume that an unknown header is dropped silently.