Why do we say that web services are stateless?
They don't persist any state between requests from the client. i.e. the service doesn't know, nor care, that a subsequent request came from client that has/hasn't made a previous request. Basically, its a 'give me this piece of info and forget about me' which puts the onus on the client to maintain any state.
Because web services are based on HTTP, which is a stateless protocol.
Quoting wikipedia :
A stateless server is a server that
treats each request as an independent
transaction that is unrelated to any
previous request.
i.e. each request is independant from the previous one : even if we use some "tricks", like cookies for instance, to preserve some state between requests, this is not something defined by the protocol.
Because HTTP is stateless. After a client request is fulfilled by the server, no information is stored for use in future transactions.
The concept of a web serivce is to model a RPC (Remote Procedure Call) aka a Function. Thus you should not need to use session. In addition, the idea of being stateless comes from the need to scale out web servers into a server farm and thus enable higher capacity.
However, the choice of using state is dependant upon the technology and the developer. There is nothing to prevent you from creating an ASP.Net Web Service and setting "EnableSession=True" in the method definition.
This can be useful in some basic authentication scenarios, i.e. home-grown forms authentication or to provide automatic correlation for short-lived "workflow"'s. (However I strongly urge you consider more modern techniques will provide a higher level of security and performance).
Requests are independent from one another.
Related
I don't have any reference to give here to show my research (because none of the links are to the point) and even Google doesn't have an exact answer. Everyone says web service is stateful but that's confusing. By principle, I believe, SOAP is stateful and REST is stateless. So, Why/How SOAP is stateful ?
Basically Stateful means that server stores information about the client and uses that information over a series of requests. So performing one request is dependant upon the state of some other request (e.g. previous). Implementing this is possible with http protocols.
So you can have stateful or stateless SOAP - it's only a matter of how you design it.
Also please note that comparing SOAP and REST is not really correct.
The first one is basically Protocol (or at least it's trying to be) and REST is just a architecture pattern/style.
I know this is not exactly answering your question but please take a look at this link: SOAP vs REST (differences)
It's extremely well written and can help you understand those technologies a bit better.
First off, SOAP is protocol. In other way we have services like REST, WSDL, WCF and many more. SOAP can be used as protocol in all kind of services. This mean, soap provide mechanism to pass data between client and server.
By design and main purpose SOAP is data protocl to be use between server and clients. Server(service) save, preserve and response data.
Soap as data can be used in both variants in service - stateful or stateless.
By default soap service is stateless. For example WSDL soap service is stateless. Simple WebAPI, REST. They are all stateless.
WCF - Single Instance is stateful.
WCF - Per call is stateless.
Being stateful is not one of SOAP protocol principles or ideas behind it. Service can be stateful or stateless.
Suppose that I have Apache/lighttpd or whatever to receive http requests. Now I want the web servers to act as a proxy for my web services running on internal servers written in Java/Clojure/Erlang?
What I want is to separate the layer that handles client connections and the server that handle application logic. These two should be separated and language independent. Is JSON or XML the format for communicating? If so, how do I perform it from the web servers?
Note: May be I missed the point of your question in this response. Pls do let me know if that is the case.
I dont think you should consider this as "forwarding" of the original request.
If your web-tier that receives the original request makes a call to one/more underlying services (thru HTTP or otherwise) it is part of the "processing" of the original request.
So, there is nothing different here than what you are already familiar with.
i.e You make a HTTP request in place where you would make a SOAP/XML request or a DB call or post a message.
When you say or think in terms of "forwarding", it is misleading.
Also, the data exchanged between your controller and services is solely based on your convenience.
It could be XML or JSON or regular POST parameters that gets sent over HTTP transport
Are all web services through HTTP and not SOAP automagically restful web services?
I have been hearing the term "Restful web services" everywhere.. but ain't it simply a plain old "web service that uses http".
I have a url at A.php and clients request data from me like this: A.php?parameters_supplied_here_etc_etc
And since the url has a length limit, for longer messages they will send a POST request with the parameters to A.php
Basically if anyone wants to talk to my server/database, it goes through the page at A.php
So can I say that it's a restful web service??
There are at least two types of web services around:
SOAP web services - using XML Schema to strictly define XML messages, typically, but not necessarily using HTTP as a transport protocol. Reliable and standardized, they've been around for quite some time, although sometimes considered heavyweight.
RESTful web services - less rigid, using plain HTTP protocol, taking advantage of built-in GET/POST/PUT/DELETE methods to perform CRUD operation on resources. Content negotiation (typically XML or JSON), redirects (Location header) and user-friendly URLs make RESTful web serives getting more attention.
These are two different communication protocols, you can migrate one into another, but no automatic conversion ever happens.
No, because to be a REST service, it needs to fulfil certain criteria. See wikipedia
There is a quote there which might answer your question better than I can:
SOAP RPC contrast
SOAP RPC over HTTP, on the other hand, encourages each application designer to define a new and arbitrary vocabulary of nouns and verbs (for example getUsers(), savePurchaseOrder(...)), usually overlaid onto the HTTP POST verb. This disregards many of HTTP's existing capabilities such as authentication, caching and content type negotiation, and may leave the application designer re-inventing many of these features within the new vocabulary.[8] Examples of doing so may include the addition of methods such as getNewUsersSince(Date date), savePurchaseOrder(string customerLogon, string password, ...).
The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object. Other (such as SOAP) are more RPC-like. SOAP refers to Simple Object Access Protocol and is usually overlaid onto the HTTP POST. SOAP has recently been stretched in some REST-like directions.
One of the cornerstones of "REST" architectural style is using HTTP to its full potential (GET, HEAD, PUT, POST, DELETE, content-type, etags, cache control, etc) instead of as a tunnel. If you do just that, you already win a lot, and I think you should feel entitled to call your service "REST Inspired" or something. From there you can use all the existing building blocks of HTTP infrastructure to your advantage, instead of having to work against them.
It's often tempting to come up with your own RPC or CRUD protocol over HTTP, and reinvent the wheel. The result is usually quite contrary to REST principles.
Are all web services automagically restful web services?
No there is no magic. You have SOAP and other protocols which are not RESTful.
If all your request go through the same URI then this is a clear sign that you're not using URIs to identify the individual resources of your system, so - no.
That being said; there are more constraints such as uniform interfaces, or hypermedia-driven.
I'm looking to add a web services interface to an existing server application. The set of services to expose is not known at compile time and can change over the runtime life of the server.
From a tech standpoint all the server/web services endpoints will be on Windows.
In our server app a user will have the option to register workflows as 'web services callable'. This will create the WSDL defining this particular workflow service.
For the calling endpoint I'm thinking of an HttpModule that accepts the inbound web service request, unpacks the request and converts the XML data types into our server applications "domain", calls the server and finally converts the server outputs back into XML for return down the http connection.
Does that make sense?
Critical comments welcomed.
In effect writing your own WS engine. Clearly doable, but quite a bit of work to get right from scratch. I guess if you find some open source implementation, then adapting it should be possible.
A rather dirtier alternative, but one I've seen applied in another context, is to go for a simgle WS interface
String call( String workkFlowName, String payload)
The payload and response are both Strings containing any XML. So the caller needs to undestand the schemas for those XMLs. From the client's perspective the amount of coding effort is not much different. Your coding effort would I think be significantly redcued.
an HttpModule that accepts the inbound
web service request, unpacks the
request and converts the XML data
types into our server applications
"domain", calls the server and finally
converts the server outputs back into
XML for return down the http
connection.
That is what all web service frameworks do (e.g. Metro, Axis). So I can't see your problem. What's your concern with this approach?
The downside for the client is that, as far as I understand it, availability of your services may change over time. So you should consider a way to inform the client if the service is available (other than getting a time out error because it is not there), e.g. WS-ResourceLifetime or UUDI.
I ended up creating a C# class that implements the IHttpHandler interface. The implementation serves up the WSDL of the services exposed from our app and accepts SOAP posts to invoke the services. In the end most of the work went on converting SOAP types to our types and vice versa.
I've been looking at http traffic analyzers which are browser addons that monitor and analyze all incoming and outgoing HTTP traffic between the browser and whatever web server you're connecting to.
The types of information available per request include:
* Request and response headers
* Sent and received cookies
* Querystring parameters
* POST parameters
* Response body
My question is whether it makes sense to use this to build a web service.
What I am interested in is using Windows SkyDrive - which offers 25GB of storage per user account - as a storage solution for my web app.
So what I am considering is using HTTP traffic analysis to figure out how to get my web app to mimic a browser interacting with my SkyDrive account.
Is this a bad solution? I have a feeling one of two things could happen quickly:
Microsoft figures out that these are automated requests and shuts down my SkyDrive account and deletes the data.
Microsoft changes the authentication front-end regularly, requiring me to repeatedly reprogram the portion of my service that interacts with SkyDrive.
Has anyone tried something like this and encountered difficulties? I would like to hear some feedback on whether this is likely to be worth the effort or not.
What you want to do is probably possible, technology wise. But is it allowed under the terms of service of SkyDrive? and what is the worst case scenario if they do change their protocols? Will you be trying to run a business off this data? Have you considered using something like Amazon's Simple Storage Service, which is designed to accommodate exactly what you want to do? Why waste your time reverse engineering the skydrive protocol?