For a client-server application, I want to develop a Web-Service which will be mainly used by the application itself (not intended for use by third parties at this time).
On the long run, however, exposing the WebService as some kind of API is generally desirable. Thus, I am already putting some thoughts in choosing a technology which allows "RESTifing" (terrible word-creation, I know ;-) ) a Web-Service easily at a later point.
WCF seems to be about right here as it provides the webHttpBinding but also other bindings which allow taking advantage of LANs and .NET clients.
The issue I now ran into is about authentification: All the authentification measures WCF provides seem to happen "outside" the actual service. However, I'd like to have a Login
method (or something more "RESTful" as shown here under point 2).
For example, I imagine writing a Service like this one:
[ServiceContract]
public interface IUserService
{
[ServiceMember]
[WebInvoke(Method = "POST", WebUri="/Session")]
public void Login(string username, string password);
[ServiceMember]
[WebInvoke(Method = "POST", WebUri="/Users")]
public void Register(RegisterUserParameter parameter);
}
How do I integrate this service into the WCF so the methods preferably work over multiple sub-services in my service project?
When using the built-in WCF authentification, I need to supply username and password before making any service call. Thus, calls to either Register
or Login
would fail because I am not authentificated.
And how can I tell the WCF to remember which user is currently logged in using my service method? Is there any possibility to store something like a session cookie inside the WCF session on the client?
Or is it generally a bad idea to realize authentification under WCF the way I am trying to?
Should I maybe directly choose WebAPI at the cost of having a more complicated way to talk to the service in my client application?