2

I have been reading a number of posts and I am leaning towards building an SOA.

My main dependencies are:

  • Need to support multiple clients
  • Need individual client environments to not effect other client environments

For example, if I want to add a text field to Client A's application, but I don't want Client B to be effected in any way.

The solution I have is to send an API address along with the client auth token. For example, the client will send something like this:

api: http://myWebsite/api/clients/ClientA/someServiceCall

Similarly, from a token, the (MVC) controller will know which view to render for a given user.

My question is, is this a good solution to my problem?

I understand that I am having to call an HTTP REST service for my data access; but, I feel this solves a lot of problems. For instance, I could see which services sending 404 errors and fix them (presumably) before they even get reported.

I have read a number of articles that seem to enforce my idea. Have I misunderstood this concept? Is there a better architectural approach?

Here's what I've been reading:

Again, the goal is to keep individual client environments as separate as possible; such that if we push a change to the service layer, there is no downtime and no one gets logged out because of an app pool refresh.

My over all plan is to incorporate these API calls wherever they are needed; i.e. in an MVC controller or a javascript AJAX call. For example:

public class HomeController : Controller
{
    public ActionResult Index()
    {
        WebClient client = new WebClient();
        string api = /* api from auth token */
        User result = JsonConvert.DeserializeObject<User>(client.DownloadString(api));
        return View(result);
    }
}
  • 2
    What do you mean by "is this a good solution to my problem?" If your goal is "to keep individual client environments as separate as possible," a sensible REST interface should really be all you need (well, except for the machinery behind it, of course). – Robert Harvey Jun 30 '14 at 23:42
  • 1
    I am fairly certain that when you deploy another build of your API, it will restart the app pool in IIS. If you do any level of state at the server (which you shouldn't with MVC, but still can), then it will become an issue if you restart the app pool. If you don't, you should be ok. – Adam Zuckerman Jul 1 '14 at 6:43
  • 1
    @AdamZuckerman Thanks but I don't think with a REST API that the app pool reset would be an issue, right? For an API, the client would send the tokens, which would hit the API server, so the user wouldn't be asked to login again or anything. That's the issue we had before, when we replace an old DLL with a new one, users would be logged out. But, I don't think this happens with an API, right? – user1477388 Jul 1 '14 at 11:41
  • 1
    @AdamZuckerman Just trying to say that HTTP is stateless, so there shouldn't be any problems with the app pool. Right or wrong? – user1477388 Jul 1 '14 at 14:36
  • 1
    HTTP is stateless, but that doesn't mean that your application is. As long as your application is stateless, you shouldn't have a problem. – Adam Zuckerman Jul 1 '14 at 19:31
2

The solution I have is to send an API address along with the client auth token. For example, the client will send something like this:

api: http://myWebsite/api/clients/ClientA/someServiceCall

I don't think it's a good idea. What you are actually trying to do here is to make separate APIs for separate client types. It will quickly become an overcomplicated task. I say: make one good API, offer it to clients as a whole and control what each client can do with it via access tokens and per-token permissions.

Similarly, from a token, the (MVC) controller will know which view to render for a given user.

I don't know how you want this to be implemented, but in my opinion web service should operate with data only. It should be separated from GUI by all means.

Again, the goal is to keep individual client environments as separate as possible; such that if we push a change to the service layer, there is no downtime and no one gets logged out because of an app pool refresh.

What is a client environment in your design? Surely not an API?

Again, the goal is to keep individual client environments as separate as possible; such that if we push a change to the service layer, there is no downtime and no one gets logged out because of an app pool refresh.

In REST model clients don't maintain constant connection to the server. So no need to care about service restarts. If you need some data to persist across calls, implement it using some data objects or tokens.

Should a website use its own public API?

I agree with Steve in that question completely. If you don't use your own API it means that API will not be... useful (pardon my word game here). But using API doesn't necessarily mean you have to actually do some HTTP calls to your service API. It means the code, working on your platform should be the same, that is utilized by your REST API. You may expose only part of the functionality via API - that's ok.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.