REST is clearly Stateless, meaning the request to the server contains all the information that the server requires to understand it, the server does not maintain a session.
Now my question is, does SOAP has to be stateful, I have worked with SOAP where the exact definition of REST would seem to be true for SOAP as well?
Now my question is Does SOAP HAVE to be state-full..
No. SOAP can be stateful, but it definitely doesn't have to be. Actually, you have to put some effort in order to achieve stateful behaviour. I suggest reading this article.
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.
I am looking for a good meaningful discussion of why people feel like it is a good idea that RESTful web services hijack HTTP response codes and assign meanings to them in the context of the given API. My intuition revolts against it: it feels that HTTP is serving as the transport layer protocol here and why would I leak my API concepts into the transport layer? Yes, I understand that HTTP is application layer in the 27 layer diagram, but layering is relative. For my API HTTP is a transport.
Now people say that otherwise error handling can't be standardized. But REST doesn't really standardize it either. We can feel good about 401 and 404 messages being somewhat intuitive, but that's bout it. What it really does is makes it harder to differentiate between and API error and API server not being there/client not pointing to the right place etc.
Which of those scenarios you think would bring better outcomes:
Re-Using HTTP status codes like 200-OK, 404-Not found, 500-Error, etc for an API layer to mean similar responses that are mostly guaranteed to be used in a standard way across all RESTful API vendors
OR
API vendors return 200-OK, and the message body contains custom response envelopes or bodies to mean similar things (like Not Found, and Error)
First scenario allows also for developing standard libraries to communicate with those APIs where the second scenario means every API is a unique case and things like error handling, caching, etc cannot be done in a standard way.
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.
If I need a web service to pass back and forth a complex object, is there a reason I should prefer SOAP over REST? Here is an example of the possible SOAP message:
<soap:Envelope>
<soap:Header>
<Credentials>
<User>Joe</User>
<Password>abc123</Password>
</Credentials>
</soap:Header>
<soap:Body>
<MyComplexBusinessObject>
<Search>
<First>Joe</First>
<Last>Smith</Last>
</Search>
...
...
</MyComplexBusinessObject>
</soap:Body>
</soap:Envelope>
Using REST, I would be asking the client to POST the following xml and authenticate using Basic Authentication:
<MyComplexBusinessObject>
<Search>
<First>Joe</First>
<Last>Smith</Last>
</Search>
...
...
</MyComplexBusinessObject>
The SOAP message is slightly more complicated, but not by much. They are still both XML, but SOAP comes with a WSDL and most programming environments will generate proxy classes for you. However, most people I talk to say I should use REST instead because it's easier to use. But I don't see how SOAP is any harder to use.
Am I missing something?
Your first requirement of "passing back and forth a complex object" constrains your architecture to eliminate many of the benefits of REST. SOAP is designed for accessing remote objects, REST is not. REST supports passing media-types as simple as text/plain, which is far more primitive than dealing with an object.
If you haven't seen it already, this question and its answers cover most of the REST vs SOAP issues.
One major benefit of REST is that all you need to call and use it is a browser and a HTTP stack - pretty much every device and machine has that. So if ease of use and reach are you main goal - use REST.
One of the major benefits of SOAP is that you have a WSDL service description and you can pretty much discover the service automatically, and generate a useable client proxy from that service description (generate the service calls, the necessary data types for the methods and so forth).
So if discoverability and a strict, formal service description are more important to you, use SOAP (with the downside that you need a full-fledged SOAP client to call your service - your web browser won't be sufficient).
SOAP isn't harder to use - but it's just not quite as "pervasive" in terms of being available - any browser can call a REST service and get an answer - but then it needs to parse and interpret that response. SOAP gets nice data structure, but you need a SOAP client for this.
I view SOAP and REST as orthogonal APIs, designed to do different things.
SOAP is basically a fancy RPC, so if you want to send a computation request over to the server and get the result back, you use SOAP. If it would be local, it would be a method call to an object instance.
REST is a way to create, retrieve, update and delete remote objects, not in the sense of POO, using a uniform API. If it would be local, it would be like working with a file.
So they actually respond to different needs. You can bastardize one to do the work of the other, but you mangle the meanings.
If you develop both the service and the client, using SOAP is as easy as REST (actually easier).
You may prefer SOAP over REST if these conditions meet:
The entire service API is complex, not just one object.
The service is used within a relatively small network, and performance is not an important requirement.
You decide to spend the minimum amount of time to develop both the service and the API documentation.