Hot answers tagged

66

From a guy who's used both SOAP and REST extensively... BOSS says SOAP is... richer and more expressive Anytime someone says a product is "rich" I want to become violently ill. I can't think of a more cliche comment to make about a technology or platform. Basically you're saying "I think this product is great, but I don't have any actual facts to back ...


58

REST is indeed an architectural style. SOAP is a data protocol. The distinction is important; you cannot compare them directly. The primary purpose of REST is to represent resources on the Internet, and to provide mechanisms for discovering them. In contrast, SOAP is used for communicating structured data between computers, and that's all it really does. ...


29

REST is much more limited than SOAP, which is its strength and the reason for its popularity. In SOAP, the set of operations allowed and the set of data types allowed is essentially limitless. SOAP is a remote procedure protocol, which you use to expose local API's across the network without losing any fidelity. This made SOAP popular in enterprise ...


17

It might be a minor point, but REST is entirely based on HTTP. SOAP does not require HTTP, and you are free to use whatever transport you like. SOAP messages can be routed asynchronously and reliably whereas REST is pretty much a synchronous paradigm. REST does not tell you anything about what the data you are sending and receiving should look like. There ...


17

I have implemented a REST API before and I really liked it. In general when you implement REST over SOAP, your client/server is more orthogonal meaning that you can a lot more freely change the server without affecting your client(s). This orthogonality is due to using a more abstract and already well defined communication via HTTP verbs. Also, the use of ...


14

SOAP or REST? Other answers do a good job of helping you argue the point from a technical perspective. However I predict a KO is unlikely simply because technically you could do most things with either approach. There are a the few exceptions that may lead to a technical knockout e.g.: if API requests should be routable through external messaging ...


10

I'll start out with this: I much prefer REST to SOAP. REST has some great advantages, if done right, like distributability, cacheability of responses, clear defined semantics, the ability to be consumed directly in a browser, and so on. However, I like arguing against myself, so here's why you should use SOAP in your next project. A lot of these points come ...


8

REST is not a standard, it is a (loosely defined) architecture. And it is tied to HTTP, which a lot of people in the corporate world saw as a limitation. So they thought they needed a general standard proper, which works over other transfer layers as well. And btw SOAP was defined prior to REST (at least according to Wikipedia :-)


8

There are really two definitions of REST: Representational State Transfer ("REST") as a principle for service design (not necessarily web service!), which suggests a uniform client-server interface where the server does not store the client context, e.g. "client has visited this page last". As a general principle, RESTful services shuold request a specific ...


8

Don't replace, add. When you achieve feature parity, stop making updates to the SOAP API and declare it deprecated.


7

It's a two step process: Convince your boss that the technical team should be the ones to chose the technical direction, not management. Chose REST. Or SOAP. Or POX. Or Whatever. Technical arguments are for technical people -- aka, people who will be doing the work. Once the boss starts to decide the technology, you have a social problem. You need to ...


7

So what does the extra overhead / complexity of SOAP give you, when do you need it and when could you and should you do without it? The biggest difference between the two is that REST is suppose to be stateless, where-as SOAP is not. In practice many REST implementation actually do implement some state in the session through something like OAuth. ...


7

Well, the famous WSHTTPBinding. It causes a lot of pain for non-.NET platforms. First of all, even if SOAP 1.2 is a standard, WSHTTPBinding is a Microsoft implementation over SOAP 1.2 and by experience, it's not as easy as "Our product support SOAP 1.2 so it'll work with WCF & WSHTTPBinding services, no problem!". Answer 1 There are two main security ...


7

Webservices are general term. They describe applications that return response to requests over web. These responses are usually something else than HTML. SOAP is specific way to make a webservice. It usually consists of complex request and response objects, usually in form of XML files. Compare to REST, where requests and responses are usually simple, uses ...


6

REST is built around the idea of doing CRUD operations on self-contained objects, or in a worst case, on a tightly coupled object hierarchy. SOAP is less structured than this, and is therefore more suitable for transactions which have a more fluid structure. SOAP requests and responses have a defined structure, insofar as they have to conform to their WSDL,...


6

I honestly think you could do either and have it work just fine. There are a ton of posts throughout the internet on REST vs. SOAP so I won't reiterate that here. But I want to show that you could use either. First, representing a sensor. Either REST or SOAP can represent such a thing. For example, anything you want to represent in XML can be done in ...


5

REST may look like CRUD, but in a Resource Oriented Architecture you can handle complex cases, though it may require some thinking. For example if you want to charge a credit card, that may seem like a verb and thus wouldn't fit with CRUD, but there's no reason you can't have a Purchase resource. Then for a Purchase POST the service can actually charge the ...


5

You can not compare REST and SOAP. REST is a architectural style whereas SOAP is a protocol. Unfortunately, REST became colloquial spoken an synonym for RESTful HTTP service, that means a realization of REST styled architecture with HTTP as (application) protocol. REST is based on following principles (constraints and elements) (in brackets the ...


4

From Wikipedia: SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. ... SOAP has three major characteristics: Extensibility (security and WS-routing are among the extensions under development), Neutrality (SOAP can be used ...


4

SOAP is way more suitable than plain HTTP for exchanging complex data structures. REST is by design practically restricted to CRUD operations, while SOAP allows arbitrary method calls, which may be something that cannot be pressed into the REST scheme.


4

I wasn't in the room, but I'd generally say SOAP was a very, very good idea and a very reasonable response to the other RPC options that existed in the mid to late 90s. Such as CORBA, a beast which I can't say I've had to personally deal with, but the mere mention of which can make grown men soil themselves. Options beyond CORBA were actually scarier in many ...


4

One thing I would mention is interoperability - if you're going to call your service from an app written in .NET and the server is written in Java (or any other combination) then go for REST. I've seen too many slight incompatibilities between SOAP implementations to bother considering it any more.


4

REST uses post as well. In-fact when using REST the http verbs tell you what operation is going on. REST and SOAP are just different standards of passing data over the internet. Having used both I would generally recommend using REST rather than SOAP unless you know the people who are going to consume your web service are using .net and Visual Studio. ...


4

I would propose a test: code two solutions that do the same very simple service. Use SOAP and a REST-ful API and compare the results. Given the toolsets today there should not be much of a difference. You can stand up a service fairly easily. Next change the API. It is my experience that a developer changing a REST API can easily make the changes because ...


4

From my understanding of REST, the implicit assumption is that all operations are CRUD operations. Certainly not. You might be referring to an experience of one particular REST web service toolkit, but in general there is no restriction like that. REST is about exchanging documents, representations of state. In fact, REST is so flexible you can describe ...


4

Your first two options are similar. In your second solution, since you could have two files with the same name in different folders, I would recommend using the size as a suffix in the file name such as images/mini/user_image_1482823_mini.jpg, images/large/user_image_1482823_large.jpg. Your third approach has an advantage in that it uses less disk space ...


4

An Anti-corruption layer is a class/ package/component that take as an input the external model and it produces the local model. For example, in a CQRS architecture, it can be implemented as a Saga: would take the events generated by the aggregates in the external bounded context and would create commands for aggregates in the local bounded context.


4

A wsdl is just a contract saying this is how you can call this service. Of course you also have (Json) webapi endpoints that don't have a formal description these days (and you could with odata you get a wsdl-ish metadata description) However soap services with a wsdl still have it's place. A new trend doesn't mean there isn't a use case for the old way.And ...


4

However, what I don't understand is how APIs are called. In other words, in a real-world scenario, people don't actually type in a URL in some input box to call APIs, so I assume the calling is done behind the scenes, by some program, and in response to some trigger event? For a web-api, there will typically be two parts. One part of the program will be ...


3

If you are doing an AJAX heavy application then one pro about REST is you have the option of using JSON as your data-interchange format instead of XML. JSON requires less markup than XML so that would speed up your application since you would be sending less data over the wire. It also seems that REST is over taking SOAP with web services, and its always a ...


Only top voted, non community-wiki answers of a minimum length are eligible