When/Why would I use Multiple Endpoints VS a Single Endpoint in a WCF service?
What is the difference between using a Single Endpoint or Multiple Endpoints in a WCF service? Are there times you would want to use one over another?
In my situation, we have two endpoints: One for Authorization and one for Data. Once you login through the Auth endpoint, you can access the Data endpoint and have access to all the data.
Is there a reason to split up the Data endpoint into multiple endpoints? The Data endpoint Contract currently consists of multiple .cs classes which all are part of one big partial class.
If your service is facing a diverse group of potential clients, multiple endpoints can make a lot of sense:
one endpoint using the net.tcp binding with Windows credentials could be used for company-internal clients that are coming from behind the firewall, which are authenticated against your company Active Directory; this binding is fast, performant, security is relatively painless to set up with AD integration
a second endpoint could be using wsHttpBinding and enforce transport-level security (https://) - so certain clients could be calling your service on a secured link
a third endpoint might be using unsecured basicHttpBinding for maximum backward compatibility - e.g. all sorts of clients (also a lot of non .NET clients like Ruby, PHP, other scripting languages etc.) could connect to this endpoint; maybe, your unsecured endpoint wouldn't be allowed to call all methods, or it might have other limitations (e.g. be handled as last priority call, only if capacity allows it)
a fourth endpoint might expose your same service over webHttpBinding in a restful way, so that even more devices, like phones etc., can connect to it
Having and exposing multiple endpoints can make your service much more easily reachable, and you can benefit from the "best possible" binding for each scenario.