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