Develop Reference

How to retrieve data from SalesForce using C#

Could somebody help me find an example of getting data from SalesForce using its api with c#? E.g. getting a Contact information by its email address?

There are ready-built libraries for .NET integration such as https://github.com/wadewegner/Force.com-Toolkit-for-NET, I'd suggest starting with one of these. (old but official). Another one could be https://github.com/anthonyreilly/NetCoreForce
Old, stable, battle-tested or you want to craft the SOAP / REST messages yourself, read up about security tokens, oauth scopes, error handling, bulk API options? I'd offload at least the login part to existing library but your call :) There are many ways to connect, there's even (paid) SQL server plugin or azure data factory solution...
".NET toolkit" seems to use old SOAP API. It's... simple. You provide username, password and you get total impersonation. The app will be able to do everything the connecting user can do. The other one seems to use client id and secret, this sounds like newer REST-based API implementation (OAuth2 keys). This is slightly better, you get extra security layer of the connected app and for example if "scope" is only set to Chatter - even admin's session connecting via this app can't be abused.
There are slight differences between the APIs and the way they handle certain features (for example downloading a Document/Attachment/File via SOAP API will give you base64-encoded payload while REST API will give you a link to download the binary separately). And of course how much of the API does the library actually implement, how well it's maintained...
But generally I'd say explore the libraries first. At least steal some ideas around login logic. If nothing off-the-shelf works for you - consume the WSDL and hand-craft something in SOAP API. Worst case - craft the XML messages manually, worry about escaping special characters etc.

Get an account and api key and then use the official programming interface:
https://developer.salesforce.com/docs/apis
i'd choose: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest_resources.htm
So You have to read and understand this: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/using_resources_working_with_searches_and_queries.htm
:)

ASP.Net Web API vs WCF, which one should I choose in my project

I have read many articles in the web so far, about the differences between WCF and ASP.Net web API. Unfortunately I could not come up to a clear idea about what will serve my purpose. Most of the Articles I have read highlighted on the design point of view of the two web services. But I am confused what will work best for my project and why? Here is my brief description of the project.
I need to create a communication channel between two servers (both are written in C#). The servers will communicate using messages (certain type of commands). The messages sometimes can be only acknowledgements, and sometimes the messages may contain instructions to do some computation. For example, one message can be draw something, or send an SMS etc. And not necessarily the messages will involve any database transactions. But the messages can sometimes send large text files as payload (around 1-5 MB maxm). What I believe WCF is very will surely do this, but can I do the same with ASP.net web API. Because so far all the example I have seen for ASP.Net web api: they are good for RESTful services that manipulate some kind of DB store (GET, PUT, DELETE). But in my case I will need to expose service points that will
do some kind of processing such as return the value of a computation, sending and acknowledging messages, etc.
Not just manipulating a DB-store.
So, what should be the best and simplest way to do so? It is needed to be mentioned that I did not find any straight forward example of achieving this using ASP.Net web API.

The Question you have asked is an overly-broad or primarily opinion-based, and its hard to give an example for what you have asked.
Important Points:
Firstly, if you are going to create a service which would be used on different platforms, then go with WCF.
Secondly, if you are creating internet service which is going to use external resource, then go with Web API.
Web API is the best choice if you are going to create a service for low bandwidth devices or mobile devices to access client.HTTP
request/response is also more readable as compared to SOAP because it
contains header, body, etc. which makes it complex.
Just take few minutes and read the below article, until you get complete understanding of few principles.
Original Source Can be found Here, Here and Here.
To whom choose between WCF or WEB API :
Choose WCF when you want to create a service that should support special scenarios such as one way messaging, message queues, duplex communication etc.
Choose WCF when you want to create a service that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transport channels are unavailable.
Choose Web API when you want to create a resource-oriented services over HTTP that can use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
Choose Web API when you want to expose your service to a broad range of clients including browsers, mobiles, iphone and tablets.
Why to choose Web API
Web API doesn't have tedious and extensive configuration like WCF REST service.
It is very simple, creating service with Web API. Where as With WCF REST, service creation is bit difficult (requires clear understanding of configurations).
Web API is only based on HTTP and HTTPS and easy to define, expose and consume in a REST-full way.
Web API is light weight architecture and good for devices which have limited bandwidth like smart phones.
My Opinion:
Simplest way to do so - Web API (Since you dont have any examples for this)
Hardest Way is (Configurations) - WCF (Better go with WCF, since you have examples)
I hope this gives you a clear idea about what to choose...

First things first, RESTful is a stateless and uniform interface norm that can be applied to web services. It doesn't have to be automatically and only plain old CRUD service backed by a DB.
In the real world, we can hardly say that all web REST API respect fully the norm, in fact they don't most of the time, especially the stateless part.
For your message based API, especially if it's bidirectional and event based, you can use websockets and consider the REST API a way to expose an uniform, stateless web interface to create those. And yes you can use websockets with ASP.NET WebApi there's plenty of tutorial out there, even for the newer ASP.NET Core.
The "between services" interactions part is no different than the usual Web browser <=> Web service, you're just using C# code instead of JS for the client.
I can hardly recommend WCF that uses SOAP since it's hardly portable considering the web standards nowadays. For instance if want to use a browser client instead of another ASP.NET service, well you'll have to do additional code client side to handle supports.
You can use WCF websockets, providing the almost all the advantages of WCF SOAP.
tl;dr :
You can mix RESTful and Websockets, it can actually be better than going full REST or full Websockets
It's personal preference to use SOAP over websockets but do comes with a potential technical debt considering what you want to do afterwards
Message API between services is no different than a message API between a service and a browser

WebAPI is not just good for RESTful webservices. You can easily send requests to a WebAPI controller and handle it the way you want : calculations, sending messages, interact with a CRM, interact with DB or anything else.
WCF was created to manage SOAP based webservices and brings extra complexity. It handles TCP, Mime...
If you just need to handle HTTP requests, the simplest way is to go with WebAPI.

I would suggest Web API if it is for RESTful services as WCF was never made to serve as Restful services although you can serve as one where as Web API was made particularly for this.

WCF vs. Web API for Windows 8 store apps

I suggested we migrate from WCF to Web API due to it being easier to implement and got shot down pretty hard. Here were the objections raised:
WebAPI is just made for rails converts
We have no need for REST or 3rd party open source support, Windows 8 Store Apps with Microsoft backend.
WCF over net.tcp is "MUCH" faster and less overhead than HTTP(S)+XML or JSON
The end comment was "I cannot think of a single advantage of using Web API over WCF.
Funny, my last job at a big MS tech based enterprise changed from WCF to Web API and dev productivity skyrocketed, lots of bugs disappeared and we never had any performance problems, but I don't want to just say that, I want to respond with facts to his points. How would you respond?

WCF or ASP.NET Web APIs? My two cents on the subject:
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication
etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF
4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based
bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers,
versioning and concurrency using ETags, pass various content types
such as images, documents, HTML pages etc., use URI templates to
include Task URIs in your responses, then the new Web APIs are the
best choice for you.
The whole article is worth a read.

Login using webservice with a remote user database

I have an online application with PHP & MySQL. I need to provide some functionality using a a desktop application built in C#. My task includes follwoing..
Authentication
Database query
Please suggest me a proper way to proceed with this scenario.
Some of my doubts..
should I use webservice in my PHP end?
How to authenticate?
any security issue?

Yes. You will need to build a webservice on the PHP end, that contains a method that will execute your query. You can then add a 'Service Reference' in your C# application to the PHP service.
Regarding authentication: it depends on your scenario. If you are the only user of the webservice you can use basic authentication (over HTTPS) to ensure that your credentials are safe from sniffers.
Problem with security is that you will have to rely on tokens, keys, or something. And because these are stored on the desktop computer that uses the software, someone can steal these secrets (by using a decompiler f.e.). If security is really important, you will need to rely on 3rd party solutions like DigiPass.

Webservice: It is the standard way of working. But it has some overhead (XML and that all) so if you transmit complex structures you might need other options (passing data with your own codification over an HTTP connection, for example). Maybe even a mixed system were simple requests are through plain webservices and more complex ones go through HTTP but without using XML, or passing a structure codified this way inside the webservice. Anyway, try to keep non-standard solutions to a minimum.
Depends of your security requirements. Webservices is HTTP, so the standard web authentication works.
Same as before, you have the basic solution, it depends of what your application does.

RESTful web services

I am new to RESTful web services. We are taking the REST route for building our public web services to be consumed by out clients.And i had a few questions.
Are there any kind of limitation with pure REST webs services? and if yes then would a hybrid REST web service take care of those limitations?
I am thinking about using SSL + Hash Message Authentication Code (HMAC) in Authorization header for security along with IP based based filtering. what do you guys think about it?
Are there any good client side tools for testing?
Currently i am using the following
http://code.google.com/p/rest-client/
And what about some kind of client side code generation tool?
The following links are my source of info.
http://msdn.microsoft.com/en-us/library/dd203052.aspx
Link

The first thing to keep in mind is that a REST service should be stateless, which is very different when compared to a SOAP/RPC type of service interface. Using REST methodology requires you to rethink how you want your clients to interact with the service, breaking down the interactions into clear and concise method calls.
REST
+ Lightweight messages, very little overhead (other than the XML itself)
+ Easily readable results, can easily test with a web browser
+ Easy to implement
- Looser interface, loose type checking
SOAP
+ More rigid, with a strict contract definition
+ Plenty of development tools available.
Looking through the WCF MSDN documentation, WCF SOAP support was integrated from the start while REST support is a recently added feature. I myself am having a hard time finding documentation for authentication/security for REST services, as most of the documentation is directed towards SOAP.
Client side generation tools: I haven't come across any for REST services as REST doesn't define a service contract as SOAP does. WADL is an attempt to do that for REST services.
http://en.wikipedia.org/wiki/Web_Application_Description_Language
http://wadl.codeplex.com/
I'm interesting in reading more responses dealing with authentication and security, as I'm looking into that myself.

This is a good starting point of a WCF REST WebService:
REST / SOAP endpoints for a WCF service
(BTW: Stackoverflow has nice REST kind of urls.)
You can test a REST service with just a web browser (Go to the url and get the XML or JSON). Fiddler is also good tool, and FireBug-plugin for FireFox. I usually make a thin service-interface project and a separate (unit-tested) logics-project.
For authentication I would first generate a Guid and a timestamp. Then based on those a hash (.NET supports SHA256 and SHA512). The Guid can be stored to server (database table) to map it some concrete numerical id. Then you can have a rest url like:
/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y
and just disable the hash & timestamp check in development environment (e.g. with AOP). With timestamp I would check that the stamp is between 15 minutes back and forward in time (=should be enough to prevent attacks).
Will your service be visible to the public/internet and is your client a jQuery or Silverlight -client? Then you still have a problem: You don't want to include a secret key in the client software code.
So you need to generate hash in server and some kind of cookie to store the client session. (This can be done e.g. with a separate login-page/application in a folder with different config-file.) I remember that this book did have something on the topic:
If you want to enable the HttpContext when using WCF, you need to set <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> under <system.serviceModel>.
Then you can check current user identity from HttpContext.Current.User.Identity.Name.
However, if you want to make a pure REST service then you don't use cookies, but a HTTP Basic Authentication coupled with SSL/TLS for each call.
I think that it's easy to make a client with just LINQ2Xml or jQuery so maybe client generation is not needed.
Or you can also have both, a SOAP and a REST interface, and use a service reference to make a client.

One thing to keep in mind is that you can take REST as a philosophy (everything should be reachable by a clean URL, without hidden strings attached) or as a dogma (you have to use PUT and DELETE even if that means a lot of hardship down the line).
The emphasis is on simplification - like using simple data types for params instead of stuctured pileups, nor clobering interface for superfluous reasons (like towing giant page "title" in a url), not using headers which are not well known and de-facto standard.
So, you can design perfectly RESTful interface using just GET and retain usability and testability from web browsers. You can also use any standard authentication methods or several of them for redundancy depending on your actual target audience. If you are making an app to run on a corpnet with standardized credentials and tokens you can continue using that. If you are doing something for very general access you can use combination of GET args and/or cookies - keeps your URL-s clean for 99.99% of users.
You can even serve both JSON and XML (like Google maps for example) and still be RESTfull, but you can't do full scale SOAP (complex input types etc). You can do limited SOAP - simple types for requests, always expressible as GET args, people still get WSDL for documentation.
Hope this paints flexible enough picture - the way of thinking above any strict dogma.