Multitier architecture using API

Question

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:

• Dogfooding: how to build a great API
• Should a website use its own public API?
• Stevey's Google Platforms Rant

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);
    }
}

Answer 1

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.