Hot answers tagged

60

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 ...


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

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


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 ...


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 ...


5

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

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

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

You do not want to store static images within a GET query (i.e. a URL with a "?"), as most HTTP caches will not hold on to the results. An improvement on option 3 would be to use custom routing so that a path like "/images/large/foo.gif" gets interpreted on the server as something like "/resize_image?size=large&name=foo.gif" (see your specific ...


3

SOA is by definition independent of any technology. SOA can be implemented using any service-based technology, it obviously encompasses all REST/HTTP applications. Based on this, ROA might be considered as a subpart of SOA that respects a specific set of guidelines of an implementation of the REST-style architecture.


3

In addition to the great responses already here, another reason might be with who you are communicating with or what language you are developing in. Some applications only have SOAP or REST interfaces. In other cases programming languages favor (by design or just practice) one protocol over the other. For example. Ruby on Rails has excellent support for ...


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 ...


3

Yes, WCF is a good fit for this. It supports everything in your list.


3

I would recommend to test the client and the server separately. Client testing The client connects to a mock server. That server verifies that the request from the client is well-formed according to your XSD specification and additional validation rules and sends a canned response back. The canned response from the mock server must have been validated ...


3

I have answered this question on StackOverflow as well - I place my answer here for easy reference... The PRG pattern alone will not prevent this, as the P action in it takes time (which is usually the case) and the user can submit the form again (via click or browser refresh), which will cause the PRG pattern to "fail". Note that malicious users can also ...


3

You have an API that uses HTTP, in my book that makes it a "web API". That's a completely generic term that implies nothing else. REST and Web Service are two examples of web APIs. Yours isn't REST and only part of it is a SOAP Web Service. I would describe it as "A web API that uses mostly SOAP but also has a more freeform endpoint that uses JSON requests ...


3

REST doesn't have anything to say about the data protocol you use. If you read the Wikipedia article, you'll find out that "In a RESTful Web service, requests made to a resource's URI will elicit a response that may be in XML, HTML, JSON or some other defined format." Naturally, you can write a web service that can return anything, including JSON, and you ...


3

I think first it's important to clarify some terminology because in this case, a lot of the terms you are using are overloaded in a number of ways. This can lead to a great amount of confusion. Specifically here, you seem to be referring to the SOAP message format but you are comparing it to REST which is a standard way to interact with the server. And ...


3

The goal is the same: have a mean for systems using different languages and operating systems to interoperate. Therefore, it's not that different after all. How should you choose one over another? It all depends on how well such or such tool is supported by the platforms where they will be used. If your intention is to make communicate two services ...


3

what should be retruned when the list is empty? In an HTTP API, the message-body of the response would normally contain a representation of an empty list. For example, if you were using application/json, then the message body would look like [] The response code would normally be 200 OK: there were no faults with the request, the server was able to find ...


2

Encryption makes sure nobody else can read your message. Signing makes sure it really comes from where it claims, and that nobody has changed the signed part. Anyone can send you an encrypted message and claim it comes from someone else, as long as they have your public encryption key. But when they sign it, they need a private key, so if the signature ...


2

SignalR has a JavaScript API. SignalR helps build asynchronous scalable web applications with real-time persistent long-running connections. Scott Hanselman wrote a great blog post about this. If that's not your speed, you may be looking for something more like WCF Support for jQuery, which seems to have sprung up from the old WCF-RIA jQuery client. Looks ...


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