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.
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.
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.
What is WSDL? How is it related to SOAP? Where does REST fit in all of that?
A WSDL is an XML document that describes a web service. It actually stands for Web Services Description Language.
SOAP is an XML-based protocol that lets you exchange info over a particular protocol (can be HTTP or SMTP, for example) between applications. It stands for Simple Object Access Protocol and uses XML for its messaging format to relay the information.
REST is an architectural style of networked systems and stands for Representational State Transfer. It's not a standard itself, but does use standards such as HTTP, URL, XML, etc.
Example: In a simple terms if you have a web service of calculator.
WSDL: WSDL tells about the functions that you can implement or exposed to the client. For example: add, delete, subtract and so on.
SOAP: Where as using SOAP you actually perform actions like doDelete(), doSubtract(), doAdd(). So SOAP and WSDL are apples and oranges. We should not compare them. They both have their own different functionality.
Why we use SOAP and WSDL: For platform independent data exchange.
EDIT: In a normal day to day life example:
WSDL: When we go to a restaurant we see the Menu Items, those are the WSDL's.
Proxy Classes: Now after seeing the Menu Items we make up our Mind (Process our mind on what to order): So, basically we make Proxy classes based on WSDL Document.
SOAP: Then when we actually order the food based on the Menu's: Meaning we use proxy classes to call upon the service methods which is done using SOAP. :)
Every time someone mentions SOAP/WSDL, I think of objects and classes defined in xml...
"You use SOAP just the same way that you would any PHP class. However, in this case the class does not exist in the local applications file system, but at a remote site accessed over http."
...
"If we think of using a SOAP service as just another PHP class then the WSDL document is a list of all the available class methods and properties. "
http://www.doublehops.com/2009/07/07/quick-tutorial-on-getting-started-with-soap-in-php/comment-page-1/
..and whenever someone talks about REST I think of HTTP's commands (request methods) like POST, GET and DELETE
SOAP -> SOAP(Simple object access protocal) is the application level protocal created for machine to machine interaction. Protocol defines standard rules. All the parties who are using the particular protocol should adhere to the protocol rules. Like TCP, It unwinds at transport layer, The SOAP protocol will be understood by Application layer( any application which supports SOAP - Axis2, .Net).
WSDL -> SOAP message consist of SoapEnevelope->SoapHeader and SoapBody. It doesn't define what would be message format? what are all the transports(HTTP,JMS) it supports? without this info, It is hard for any client who wants to consume the particular web service to construct the SOAP message. Even if they do, they won't be sure, it'll work all the time. WSDL is the rescue. WSDL (Web Service description Language) defines the operations, message formats and transport details for the SOAP message.
REST -> REST(Representational state transfer) is based on the Transport. Unlike SOAP which targets the actions, REST concerns more on the resources. REST locates the resources by using URL (example -http://{serverAddress}/employees/employeeNumber/12345) and it depends on the transport protocol( with HTTP - GET,POST, PUT, DELETE,...) for the actions to be performed on the resources. The REST service locates the resource based on the URL and perform the action based on the transport action verb. It is more of architectural style and conventions based.
You're not going to "simply" understand something complex.
WSDL is an XML-based language for describing a web service. It describes the messages, operations, and network transport information used by the service. These web services usually use SOAP, but may use other protocols.
A WSDL is readable by a program, and so may be used to generate all, or part of the client code necessary to call the web service. This is what it means to call SOAP-based web services "self-describing".
REST is not related to WSDL at all.
SOAP stands for Simple (sic) Object Access Protocol. It was intended to be a way to do Remote Procedure Calls to remote objects by sending XML over HTTP.
WSDL is Web Service Description Language. A request ending in '.wsdl' to an endpoint will result in an XML message describing request and response that a use can expect. It descibes the contract between service & client.
REST uses HTTP to send messages to services.
SOAP is a spec, REST is a style.
Wikipedia says "The Web Services Description Language is an XML-based language that provides a model for describing Web services". Put another way, WSDL is to a web service, as javadoc is to a java library.
The really sweet thing about WSDL, though, is that software can generate a client and server using WSDL.
Some clear explanations (for SOAP and WSDL) can be found here as well.
Difference between a SOAP message and a WSDL?
REST is light-weight in terms of encoding, much more useful for light weight devices i.e. non strict APIs.
REST is format independent. XML, HTML, JSON all options are available.
REST provides abilities for on 2 point message transfer (not surprising since REST stands for REpresentational State Transfer) where WSDL/SOAP interaction is multiple point message interaction.
REST does not require a new extension for XML messages, where in WSDL/SOAP this is the case.
WSDL/SOAP uses multiple transport protocols, REST relies on only HTTP. Therefore WSDL/SOAP can be used like a RESTful way, however simple requests can be overly complicated/heavy weighted.
A simple analogy: REST is like a motoboy delivers your food easy and quick. XML extended WSDL/SOAP more like UPS delivery, more structured and serious stuff but comes with a cost.
A WSDL document describes a webservice. It specifies the location of the service and the methods of the service using these major elements:
data types using in webservice
data elements for each operation
describe the operations that can be performed and the messages envolved
SOAP (Simple Object Access Protocol) is a messaging protocol that allows programs that run on disparate operating systems to communicate using http and xml.
I am currently reading on Web Services. There is a SOAP tutorial at http://www.w3schools.com/soap/soap_intro.asp . The following paragraph is from that page:
"Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic."
I don't understand this. Can someone explain it to me, please. Escpecially I want to know, why RPC is a security problem (at lease over HTTP). Knowing why exactly it is a compatibility problem would be nice, too.
The point they're making is that "traditional RPC" sometimes uses unusual low-level network protocols that often get blocked by corporate firewalls. Because SOAP uses HTTP, it's traffic is "indistinguishable" from normal web page views, and so is not caught out by these firewalls.
Not too sure about the security point, I think they're probably implying that HTTP can easily be secured over HTTPS and that proprietary RPC protocols often don't. Of course, this is protocol dependant, not all RPC protocols will be insecure, and many of them can be tunnelled over HTTPS.
Regarding compatibility, the problem is that it's not obvious to make something that uses DCOM talk to something that uses CORBA, for example. One of the aims of SOAP is to provide interoperability, so as to harmonize the way this sort of communication is implemented. (There may still be a few glitches regarding interoperability with SOAP, depending on the tools you use.)
Regarding security, for a long time, policies have been made around using port numbers to distinguish applications: if you want to block a certain service (say NNTP), you block its port at the firewall level. It makes it easy to have a coarse control over which applications may be used. What SOAP over HTTP does is pushing the problem at the layer above. You can no longer distinguish which application or service is used from the port number at the TCP level, instead, you would have to be able to analyse the content of the HTTP message and the SOAP messages to authorize certain applications or services.
SOAP mostly uses HTTP POST to send its messages: that's using HTTP as a transport protocol, whereas HTTP is a transfer protocol, therefore not using HTTP in accordance to the web architecture (SOAP 2 may have attempted to improve the situation). Because almost everyone needs access to the web nowadays, it's almost guaranteed that the HTTP ports won't be blocked. That's effectively using a loop-hole, if no security layer is added on top of this.
This being said, in terms of security, there are advantages in using HTTP for SOAP communication as there is more harmonization in terms of existing HTTP authentication systems for example. What the SOAP/WS-* stack attempts to do is to harmonize the "RPC" communications, independently of the platform. It's not a case of "SOAP is secure" v.s. "DCOM/CORBA isn't", you still have to make use of its security components, e.g. WS-Security, and you may have been able to achieve a reasonable level of security with other systems too.