I have been building a console app the uses the Saleforce SOAP API, and now need to use the Salesforce API in a web app.
Am I correct to assume that SOAP is better suited for a non web-based app, and REST is better for a web app?
If I where to create a wrapper that would be used in either reporting from local apps, or posting to salesforce from our websites, should I expose both the REST and SOAP api's, depending on what the app is? Or should I just stick to using one? What are deciding factors I should look at if I just need to pick one?
The other answers contain some good general info, some salesforce specific things to take into account are
1) You can directly bulk update data in the SOAP API, but you'll need to use the Async Bulk API to do that from REST.
2) The soap API contains a few things not available in the REST API, most notably describeLayout, queryAll, getDeleted & getUpdated
3) the REST API contains a few things not available in the SOAP API, including the API for chatter, and access to the recently accessed records lists.
4) the REST API can access binary data (files, attachments, content, etc) without the overhead of base64 encoding/decoding.
So, depending on exactly what your app is trying to do may push you one way or the other.
I believe it ends up being personal preference if you're consuming it by a .NET application, regardless of whether it's a web app or not.
Personally, I would go with SOAP as .NET has a lot of built in functionality to consume a SOAP service, it builds all the method prototypes for you and will make development faster than you handcrafting REST requests yourself. .NET will take care of the marshalling of SOAP.
As for building a wrapper, you have to consider your target audience, if your target audience is other .NET application developers, then exposing your own WCF service might be a decent option, WCF also has endpoints for either SOAP or REST.
IMHO, if you are developing the solution from .NET as your question indicates, SOAP is the way to go. REST services are beneficial because they lack the bulk and tool set requirements that surround SOAP and are nice for the bootstrap developer without access to heavy investment tools like .NET. I agree with the other comments that REST more closely mirrors the underlying HTTP methodology, and is easier to read and parse explicitly, but that isn't really something you have to concern yourself with from within a tool like VS and .NET.
Additionally, since you have existing console apps that may be brought into the communication mix at some point, it might be good to have the WCF flexibility to be transport agnostic and not tied to HTTP as you would be with REST.
So I really don't think you are in a position to take advantage of the REST advantages or be impacted by the shortcomings of SOAP, so it makes sense to go with the heavily standardized option that fits best into your existing tool set.
The decision to use REST or SOAP when both are available is usually related to:
The tools and language you're using for your application
Your familiarity with either style
The performance needs of your application (JSON payloads are smaller than XML payloads)
If the 'local' apps are calling the services from the server side, then all else being equal, you can at least generate C# code directly from the WSDL and that makes using the SOAP API simpler (no hand coding).
If the web application needs to call the API directly from the client side (browser), then use REST and work with JSON. This will be far simpler. You wouldn't be able to reuse the same wrapper regardless, so no problem using two different APIs other than the time it takes to learn them.
If the web app usage of the API is on the server (not client) side, then definitely target just a single API. WSDL if you want to auto-generate the code to call it, REST otherwise for simplicity and efficiency.
IMO, SOAP was a standard created as a contract type messaging architect, I.e. When passing messages just use this "contract." It was generic enough that it doesn't embrace any particular technology.
REST is a actual methodology that embraces HTTP, it is a way of utilizing GET, POST, PUT and DELETE to it's max potential.
I wouldn't assume one is better then the other, what it really boils down to is using the right tool for the job. I wouldn't make a distinction between web-based app and non web-based. Because SOAP or REST can be beneficial to both.
Here are a few questions I would get answered first:
1) Who is my target client. Microsoft Workshop Client, Java, PHP type.
2) What types of (Lack of a better term.) "Endpoints" do I want to expose to my Api. (JSON, XML, Ajax, POX or all of the above.)
3) What will my clients be going with this API? Do they already have clients that are based on SOAP. If so, SOAP is the way to go.
4) REST will makes you think about your URL design and thus allowing a client to "mashup" data to build what they need. So if you think that's something you want. REST is the way to go.
5) REST makes use of the "GET" in HTTP, this allows a client to cache results. "Conditional GET is what it's called. It allows them to cache a big object, ask the server via just a header (small) if the last update matches what is cached, if so. don't bother with a full object GET, what is cached is the latest version. This can be done in SOAP, but out of the box, REST is better for this.
Anyway, hopefully that gives you the better data, so you can make the better decision. And if all else fails you can just do both. But then you'll have to deal with trying to get two types of services (different methodologies) and one codebase for both. (can be tricky, but not that difficult.)
Personally. I would pick one, then if you ever need the other, burn that bridge and pay the technical debt for it.
Late to this party, but just a quick note:
The Salesforce API isn't completely RESTful: I would call it REST-ish. It has SQL-like queries in URLs for some of its REST interface, that sort of thing.
SOAP API:
What is it for? Integrating your organization’s data with other applications using SOAP.
When to use it? You have pre-existing middleware services that need to work with WSDLs and XML data.
Protocol SOAP/WSDL
Data format XML
Communication Synchronous
REST API:
What is it for? Accessing objects in your organization using REST.
When to use it? You want to leverage the REST architecture to integrate with your organization.
No WSDL requirement.
Well-suited for browser-based applications, mobile apps, and highly-interactive social applications.
Protocol REST
Data format JSON, XML
Communication Synchronous
Related
We are creating an API that suits the benefits of a REST based architecture. However where I struggle is in how easy it is to consume from different technologies.
Its a c# WCF service and if consuming via c# is a doddle, 1) give the dll with the contract to the calling project 2) use the WebChannelFactory generic to wrap the contract before calling the url and method.
However given this is an API I want other non .net based systems to be able to interract with it. The argument I hear is that why should developers read all the documentation for the REST based service, manually create a http request (in their language of choice), and then parse the response. When if we created a web service using SOAP all they would have to do is add a reference to it and let their technology of coice build the call and response objects for dealing with the SOAP and make the call using a few lines of code (I know its this easy in c# and apparently java is easy too).
Seems like from a consumption perspective from differing technologies that support SOAP and building references from WSDL's that SOAP wins hands down. But I really want to use REST just have this argument and I cant really argue with it.
I have only ever seen one argument for SOAP in favor of REST that I completely agree with, and your question makes it: Use SOAP if that is what the client/customer/user wants. If it really is the case that all of the consumers of this service can more easily use SOAP, then you should go with that.
Of course, if you want to support a client platform that does not have built-in support for SOAP, that could be another matter. You don't want your client/customer/user building a SOAP client layer from scratch, unless you just really don't like them.
I also definitly recommend using SOAP for such a purpose.
You already mentioned most of the benefits for SOAP against REST.
Why do you even really want to create a REST service if all facts point you to SOAP?
For me REST only has the advantage of faster access, but in most use cases its not that much that it would justify not to use the advantages of SOAP.
BTW: If you create a normal .net WebService you get both "for free", because they support SOAP and REST by default (maybe you need to enable on ore another in the web.config).
The reverse argument is that SOAP only works on platforms that have a WSDL parser and SOAP stack in place. Without one it's completely impractical to ever use it, whereas REST can be boiled down to "send HTTP request, parse results as XML".
Yes, for certain types of APIs on platforms that support it SOAP will be easier to work with. And in other cases its not. :) It really depends on what you're trying to do.
In WCF it's not terribly hard to enable both, so it might be worth it to do that and let the people using your API choose what they want to work with.
It sounds like what you're struggling with is that the industry is tending to move away from SOAP based services in favor of REST, but the tools for consuming such services are lagging.
One benefit of developing your service with WCF is that you abstract the endpoints (SOAP, REST, etc) from the actual application. Therefore, it seems premature to rule out SOAP or REST.
An approach might be to make your service by defining sound objects that you would like to expose for consumption. Once you've developed this, start trying to consume the service from different platforms/tools. You may learn that consuming a REST service is not as difficult as you might think. However, you may also learn that you simply do not need REST at the moment, but always have the option to turn it on if need be.
From what you've described, REST is your best option.
Here's something to consider:
There're several standards using SOAP, MS promotes WS-I Basic Profile 1.1 which is not so widely supported outside of MS world and people could easily have troubles connecting to your service.
REST have many advantages over SOAP just by utilizing HTTP (testing, caching, etc.). Although if you need complex security or messaging, REST won't support this out-of-the-box.
Using REST-services is really easy from anywhere, without any framework or tools.
I'm interested in gaining a better understanding of WCF.
Of course, I can read books and tutorials about it, but it seems that a better way would be to actually come up with some project idea (either open-source or a startup) which would actually benefit from using WCF, and then build it using WCF.
What are your ideas for small-scale projects which might benefit from WCF?
I'm not sure it is really a matter of scale that drives a decision to use WCF. If a learning project is all you are interested in, then take a normal idea for a project, and turn the entire data access layer into WCF calls.
This should give you a fair understanding of all the little nooks and crannies of WCF, and allow you to fail in a controlled manner. That way you can make decisions in the future about when are where it is best to apply a service boundary using WCF.
As was already mentioned, anything to do with the web can benefit tremendously from WCF. Heck, you could build a pure JavaScript and HTML 5 application using WCF without ever touching ASP.Net.
A hosted service that a mobile device (such as a WP7 or iPhone) could connect with to retrieve data
WCF is great for setting up non-ASPX endpoints for Ajax clients. See for example this article. There are many more out there.
Any project involving .NET and communication is likely to benefit from WCF. WCF is the replacement for ASMX web services and for .NET Remoting. There's no one particular type of application that it is suited for. For instance, it's not like it's suitable for Enterprise applications but not for small ones.
WCF data contracts are very easy and handy for storing application configuration, settings and state. Write a library/application to take care of serialisation and editing.
This question already has answers here:
Why do we need RESTful Web Services?
(8 answers)
Closed 9 years ago.
Why and when to use RESTful services?
I know how to create a WCF webservice. But I am not able to comprehend when to use a SOAP based service and when to use a RESTful service. I read many articles on SOAP vs REST, but still, I don't have a clear picture of why and when to use RESTful services.
What are some concrete points in order to easily decide between these services?
This is a worthy question, and one for which a short answer does no justice. Forgetting about the fact that most people may be more familiar with SOAP than REST, I think there are a few key points in this:
First and foremost, I would suggest using REST wherever it fits naturally. If your main use scenarios involve reading and updating data atoms ("resources"), REST provides a more lightweight, discoverable and straightforward approach to data access. Also, building really thin clients (mobile devices, JavaScript, even shell scripts) is often easier with REST.
For example: If your data model is all about customers and your main operations involve reading the customers and writing back changes, REST will do just fine. Using GET/POST/PUT/DELETE HTTP protocols is an excellent way to make the protocol very discoverable and easy to use, even for somebody not intimately familiar with your application.
This, however, brings us to the second point.
What if you need to offer a web API with querying capabilities? For example, a typical scenario might be "Get me the 5 newest customers". In this scenario, pure REST provides little in terms of API discoverability. Enter OData (www.odata.org), and you're rolling again; from this viewpoint, OData URI based query syntax adds a touch of well-known abstraction above the normal extremely simplistic, ID-based addressing of REST services.
But then, there are aspects which can be reasonably hard to represent in terms of REST. Point three: If you can't model it reasonably cleanly, consider SOA.
For example, if a common usage scenario involves transitioning customers between workflow stages (say, "new customer", "credit request received", "credit approved"), modeling such stages with REST may prove complex. Should different stages be represented just as an attribute value in an entity? Or perhaps, should the different stages be modeled as containers wherein the customers lie? If it's an attribute, do you always want to do a full PUT when updating it? Should you perhaps use a custom HTTP verb ("APPROVE http://mysite/customers/contoso HTTP/1.0")?
These are valid questions to which there are no universal answers. Everything can be modeled in REST, but at some point the abstraction breaks down so much that much of REST's human-facing benefits (discoverability, ease of understanding) are lost. Of course, technical benefits (like all the HTTP-level goodness) can still be reaped, but in most realities they're not really the critical argument anyway.
Fourth and finally, there are things which the SOA model simply does great. Perhaps the most important of these is transactions. While it's a pretty complex generic problem in the WS-* world as well, generic transactions are rarely needed and can often be replaced with reasonably simple, atomic operations.
For example, consider a scenario where you want to create an operation that allows the merging of two customers and all their purchases under one account. Of course, all this needs to happen or not happen; a typical transaction scenario. Modeling this in REST requires a nontrivial amount of effort. For a specialized scenario such as this, the easy SOA approach would be to create one operation (MergeCustomers) which implements the transaction internally.
For more advanced scenarios, the WS-* stack provides facilities not readily available in the REST world (including WS-Transaction, WS-Security and whatnot). While most APIs need none of this (or are better off implementing them in a more simple way), I don't think it's worth the effort to rewrite all that just to be 100% REST.
Look into the best of both worlds. For the vast majority of scenarios, it is completely acceptable to have the basic CRUD in REST and provide a few specialized operations in SOA.
Also, these APIs can be designed to act together. For example, what should a SOA-based MergeCustomers operation return? It might return a serialized copy of the merged customer, but in most cases I would opt for returning a URI of the REST resource that is the newly merged customer. This way, you would always have a single representation of the customer even if SOA were necessary for specialized scenarios.
The previous approach has the drawback that it requires client support for both REST and SOA. However, this is rarely a real problem (apart from the purely architectural perspective). The simplest clients usually have REST capabilities by the very definition of having an HTTP stack, and they rarely run the more complex operations.
Of course, your mileage may vary. The needs of your application (and its clients), local policies and backward compatibility requirements often seem to dominate these discusssions in forehand, so the REST vs. SOA discussion is rarely on a pure technical merit basis.
An eternal question! SOAP vs. REST....
SOAP is great because it's industrial-strength, the services are self-describing in a machine-readable and -interpretable way, e.g. your computer can read, understand a SOAP service and create a client for it. SOAP is great because it's methods and all the data it will ever pass around are described and defined in great detail. But SOAP is a bit heavy-weight - it takes a lot of infrastructure to support it. SOAP is also mostly method-oriented, e.g. you define your services by means of what methods can be executed on the service.
REST is much more light-weight - it uses only established HTTP protocol and procedures, so any device that has an HTTP stack (and what doesn't, these days) can access a REST service. No SOAP heavy-lifting needed. REST is also more resource-centric, e.g. you think about resources, collections of resources, and their properties and how to deal with those (so you're basically back to the core function of create, read, update, delete). REST doesn't currently have any machine-readable service description, so you're either left to try and see, or you need some documentation from the service provider, to know what resources you have at hand.
My personal bottom line: if you want to expose some collections of data, and reach (being able to access it from any device) and ease-of-use is more important than reliability and other enterprise-grade features, then REST is the way to go. If you need serious, business-to-business, well-defined, well-documented services that implement things like reliability, transaction support etc. - then you're definitely on the right track with SOAP.
But I really don't see a REST exclusive or SOAP kind of approach - they'll be great scenarios for both.
SOAP will give you a richer set of functionality and you can create strongly typed services, where REST is normally more lightweight and easier to get running.
Edit: If you look at the ws-* standards there is a lot of stuff http://www.soaspecs.com/ws.php. Development tools such as Visual Studio make access very easy to a lot of this though. Typically WS is used more for enterprise SOA type development while REST is used for public API's on web sites (at least thats what I think).
Android (mobile OS) do not have support for SOAP. RESTful services are a much better suit when mobile devices are the target.
I personally prefer RESTful services in most cases since they are more lightweight, easier to debug and integrate against (unless you use a code generator for SOAP).
One point that hasn't been mentioned is overhead. A recent REST project I worked on involved file transfer with items up to 2 GB allowed. If it had been implemented as a SOAP service, that'd be an automatic 30%+ increase in data due to encoding. The overhead with a REST service is all headers, the rest is straight data.
I have been working with webservices for over 2 years now. I have lot to say about services like Soap 1.2, WSDL, the way communication is taking place and 100 of other things.
I have seen people talking about their heavy ASMX background and web services expertize. But, when it comes to implementation I don't find anything but adding a web reference and calling few methods from C#. All the things that we talk about (serialization, deserialization, soap, blah blah) is taken care by Microsoft internally.
So I want to know if it is all we have to do while dealing with WebServices or is there anything more to it?
Rephrase: I wana know what an expert of ASMX must know about these services.
I'll appreciate if you can provide some good references, material or any comments on this.
I think you are approaching this from a implementor/tools standpoint; yes, Visual Studio does a lot of the heavy lifting to make a developer feel like calling Web services is the same as calling any method -- but developers who use the tools blindly without knowing what code is being generated and how it all works are, as you suggest, not experts.
To say you are an expert, I think you would need to be able to talk about things like the following:
Pros and Cons of using services in your architecture (performance considerations, versioning issues, synchronous versus async, etc.)
Reasons you would want to use ASMX versus WCF
Internal implementaiton of the SOAP protocol, how SOAP headers can be used for security, etc.
Knowledge of the "internals", so you could potentially expose services for consumption by non-Microsoft clients (java, etc.)
Features of WSE, including the different versions
Security concerns -- how to secure access to a service, and how to secure the data being transferred back and forth
If you want to consider yourself an expert in ASMX, then you need to understand the SoapExtension class and the related SoapExtensionAttribute. I do not feel that it's necessary to understand SoapExtensionImporter and SoapExtensionReflector.
You should also understand XML Serialization, since that is what is used to serialize and deserialize between objects and SOAP in an ASMX service.
You should also understand that Microsoft now considers ASMX web services to be "legacy technology" (reference on request).
I would say that just knowing ASMX and/WCF basics doesn't make an expert out of you from a web service point of view.
It is true that all the plumbing is taken care of, but you generally have to go back to it at one point or another. It's always very easy to connect asmx to asmx, wcf to wcf, axis2 to axis2... But once you start to make these communicate together, problems start to show. Did you ever worked on a project using web services where at some point you had issues with the generated WSDL, or the generated proxy?
I would say that for someone to claim being asmx expert, he shouldn't look surprised if you start talking about soap 1.1 and 1.2, WS basic profile, WS-*, and all those things that apears to be abstracted away at first sight, but which you'll have to come back to at some point.
The company has a PHP app that is in horrible condition. They want to start making plans to redesign it in .NET, however they need to run with the current design because of various reasons that I won't get into here.
They want to make some enhancements to the current design but do it in such a way that those enhancements can be in-part reused by their .NET version when it comes along. One idea to do this was to make the data and business logic portion of the app reside as a .NET webservice that would be consumed by the PHP end.
My question is will this cause problems in PHP? Can PHP consume .NET web services quickly and efficiently? Or is this just a bad design decision?
My question is will this cause
problems in PHP? Can PHP consume .NET
web services quickly and efficiently?
Or is this just a bad design decision?
I have two thoughts here. First to answer your question directly. I don't believe it's a bad design and if the .NET services are written language agnostic then there should be little issue.
The second thought is a "hope". I hope the choice to go with a .NET framework was not due to poorly written PHP. Changing languages because of poor implementation in my opinion is where the design fails. There will be more effort converting to a new language than there would be if the company choose to re-write the PHP and the end result would be a single unified language base with built-in legacy support. But then I'm a PHP fan.
For PHP to consume .NET webservices quickly you'll need to use PHP5 native SOAP Client API, enabling cache to store WSDL locally. If you use PHP4 you can use Nusoap, but it isn't as fast as native classes.
The whole point of having a webservice is interoperability between various development platforms. For instance twitter is a rails-based website and its services are consumed by multitude of various desktop and web applications written in .NET, java, python, etc, through its RESTful web-api. Facebook is PHP and C++ based as far as I know and how many webapps consume it's services through api. SO I don't think it's a bad idea. The question is how you implement this webservice. Meaning, do you want to use it once and then get rid of it or sue it for a long time. If the second option is true - make sure you design your webservice api with that in mind. Also PHP can easily consume XML-RPC and SOAP. I used both ( provided by a Perl based service) without any problem or big hits on performance.
I think using .NET to migrate from PHP is not the smartest choice - but that is somewhat subjective opinion. In my experience it almost always ended being an overkill, badly designed, more expensive to maintain and more buggy - because of the nature of the beast.
P.S.:
I'm not a PHP fan, but I don't believe in converting to .NET for the sake of converting. Also .NET infrastructure is more expensive to maintain and much more labor intensive.
The primary advantage of a webservice is its interoperability, or ability to be consumed by others independent of language. PHP should have something that allows it to consume webservices so that shou;dn't be too big of a deal. The disadvantage will be that it may be a little slower, but this is something you'd have to test out to see how much of an impact that has on your overall solution. Generally most solutions aren't inherently right or wrong, you have to test their usefulness to your particular circumstance.
PHP can consume .NET web services fine, as long as you stay away from WSHTTP based web services and use BASIC HTTP. You can secure BASIC HTTP web services with SSL for security.
WHen you are in Visual Studio 2008, and you have an ASP.NET (could be MVC or not, doesn't matter) project open, right click on the project and select "Add New Item." You will see see something under Web, called Web Service. This will create a .asmx file and you can find tutorials on how to create these basic web services.
Another alternative is to use Windows Communication Foundation, which has a lot of helpful classes, but it can be more complicated. The default configuration for a WCF service is WSHTTP, but it is possible to make a BASIC HTTP web service with the WCF too.
Not really much of a problem at all, just investigate your options.
Web Services can output data in a wide variety of formats. SOAP/XML are the default but there is no reason why you can't do YML, Xml serialized objects, or my current favorite JSON (which makes calling into it from a browser really easy).
Look also into WCF services, I believe they're supposed to supplant the Web Service format.
Finally, if you're looking for best practices check out Service Oriented Architecture. Its a large and varied field and this is exactly the sort of things they talk about.