I am working on a project in MVC that has mobile application so one thing is clear that we have to use Web API so it can used in mobile application.
After creating API when we started to develop Web site we are confused and had discussion on whether to use API or directly access to the Business object. And we ended up after having opinion form more experienced developer to consume Web API instead of using Business object directly.
I'm having confusion regarding to this solution structure.
1) Why we should use Web API and make HTTP request (which is time consuming) to get or put data instead of business object directly which is in same solution.
2) After having arguments they said what if client wants to host API and web on different cloud server and apply scaling only on API or may be he want to have different url for accessing API and Web (which is some what logical). So in that case should we call Web API from MVC application in same solution?
3) If we're hosting API and Web on different hosting so it means our Web will use WebClient and have HTTP call on each navigation. Is it right?
4) If we'll business object form both API and Web hosting on different server then if something change in BL will need to update build on both server.
5) Or we should create only one project for API and can add views or html pages to develop Web interface so in that way we can directly call API from ajax.
As per my knowledge #5 is the best solution or API is only for 3rd party access. If we have DB, EF, data layer and business layer in same solution then we should not use API to make HTTP calls and directly access business object. (correct me if I'm wrong)API is needed when mobile application or desktop or any one want to access application so we can have same repository and data layer.
In my scenario I've to create API as we also have mobile application, and in project API side we called business layer (separate project) and business layer communicate to data access layer (separate project). So my question is if we host our API and web to different servers then calling API which is a HTTP request may take longer rather than using method from business layer as we create the project and we've .dll of business layer. In API controller we just convert out put of our business to json format.
I've searched on internet but didn't get convincing answer. I've found a blog http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx discussing same point but again in that blog my question is why we need to consider scenario #3?
I think you have answered your own question in writing, but really this boils down entirely to what your requirements are, and perhaps more importantly, what the strategy for your application is.
First of all, using Web Api over accessing Business Objects directly (by which I think you mean through viewmodels etc) only makes sense if you are controlling access of data client side.
If you only have a requirement for consuming data from client side within a particular application, then hosting Web API within the same project makes sense. Sometimes, for instance when building a SPA or rich-client web app, then using Web Api within the same projhect is sufficient, as they are only intended to be consumed by that application.
Where you see a requirement for different versions of the same application (mobile, tablet, web etc), then moving the Web Api to a separate project makes sense, as each application can then access the same API. This Web Api would contain your data access and business logic layers within it. This allows complete separation of your projects then, and provides maximum reusability, and ensures consistency in data between different versions of your project. Obviously with this set up, your Web Api layer is seperate and can be tested/deployed/scaled separately.
So in summary, you need to consider your requirements and assess the technologies available to you to achieve them. Using the above I hope you understand where Web Api fits in and what it can provide.
Related
I am building a RESTful api for a project at the moment, the API will used for a web application, a mobile application and maybe eventually a desktop application.
There are a few instances where emails need to be sent to notify the user of an event that has happened within the application. What I am not sure of is where to does a an APIs job finish, should the API be responsible for sending the emails, or should the application send the emails based on what response comes from the API?
Basically what I am asking is where does an APIs job start and finish, is an APIs job just getting date from point A to point B? Or can it deeper capabilities?
It's a common mistake that many developers are still making. An API is just an interface through which you expose your underlying system to be accessed by other systems. How you expose your system depends on what functionalities you want to be visible to the external world. Moreover, your business logic should be entirely on your backend rather than spread over your mobile/web applications.
Having said that, my answer is yes! Don't think of it as "my API is sending emails". Think of it as "my MAIN SYSTEM is sending emails". Whether you want to expose this email functionality through your API or not is another completely different thing.
I am new to web dev but I have managed to build my site using GWT and GAE. I use RequestFactory for client-server communications.
Now, someone wants to make mobile applications that use my backend.
I have found that RequestFactory works very well with Android. But I am somehow afraid it will not work with other "not-google" front ends (iOS for instance).
So my question is, can I make an API based on my RequestFactory backend (servlet) that can be used by any client? Any initial pointers as to how to implement it would be appreciated.
I guess technically it would be possible. However, if you want to create an api anyone can use, you probably want an api were you specify both how to communicate with the api and the content send/received by the api. With RequestFactory both the how and what is shielded by RequestFactory. So if someone wants to communicate with your api and can't use the RequestFactory code in the project, the how and what of RequestFactory must be reverse engineered, and could change anytime because it's not guaranteed. Not the most elegant way to go forward.
A better approach is define an open api were you specify the how and what. For example with
and apu based on REST (the how), communicating JSON data, and to specify the content format (the what). An example of such an api is the twitter api.
For your own project you could build on your api also, for example by using RestyGWT. Then you don't have to maintain both the code for the RequestFactory interface and REST interface. For other platforms there are probably several libraries available to make developing against a REST interface easy.
I am about to create a simple web app and I am wondering if I should use ASP.NET MVC 4 new feature Web API.
What's the best way to do this ?
I've done some researches and I found out there are two option :
Option 1
Make the Web Api my service layer and call it from the controller to read/write data, and render the view using view models and razor.
Option 2
Make the Web Api my service layer and call it directly from the view using Javascript.
I am not a big fan of Option 2 since I feel like I am neglecting the controller which will be used only for redirection between pages. Besides I prefer using razor rather than Javascript.
And If I choose Option 1 will I have to make an instance of one Web API in the controller? because this feels like I am doing something wrong.
What's the best option ? Is there any other options I haven't considered ?
And if you can give some references or books which can help me, I would appreciate it.
Thanks.
I usually have another layer (which can be a different project/assembly depending on the size and complexity of your application) for my business rules. You can call this business services, or whatever works on your case.
So both MVC controllers and API controllers use this layer; which keeps the application dry.
I personally prefer to only keep complex operations in my business layers, which means if I need to read something from my persistence layer to display in my views, I do it directly on the MVC controller. This is a matter of personal preference but I prefer to go the CQRS way.
So you MVC controllers are going to instantiate these business services (or they will be injected into your controllers if you are using IoC). For read operations you can choose to go straight to your persistance layer or use another read strategy.
The same will happen to your API controllers, they will use this "common" layer of services.
You don't need to instantiate your API Controllers on your MVC Controllers.
Consuming your Web Api controllers via AJAX is ok if you are developing a SPA or similar.
There is no a single way to structure your application, there are just different ways and every one has more or less pain attached.
If you are considering introducing tests in your applications (and you should :)); then you should structure it in a way it is easy to test each part of it.
Just my 2 cents.
The whole point of Web API is to be a stateless RESTful service. There would never be an instance of it if you're doing it right. I realize this question is old and you may personally have learned this, but the answer isn't as much for you as it is an answer to a frequently-asked question.
Note that when speaking of Web API, more often than not, people are talking about ApiControllers and not basic MVC "Controllers" that take routes and turn them into Views.
So in your project, you may have some "Controllers" which do some basic view logic, but no business logic. Don't confuse that with your Service Layer which is a wrapper for your Business Logic and Persistence access.
I, and many, am of the opinion that ApiControllers shouldn't be mixed with your MVC application. Keep in mind that MVC does not mix well with Web API. As Filip W says:
Many of the concepts used by Web API and MVC, even though similar at
first glance, are actually not compatible. For example, Web API
attributes are System.Web.Http.Filters.Filter and MVC attributes are
System.Web.Mvc.Filter - and they are not interchangeable.
Most flexible answer
So what you do is create a subdomain named api.YourWebsite.com, and build a new Web API ApiController project there. That Web API Project should do NOTHING more than instantiate and expose Business Logic via ApiControllers and Dependency Injection.
Alternative 1
Service-Oriented Architecture is all about reusability. If you want to keep your applications DRY, you should definitely fall into SOA. Though, every situation is different. If you will never ever use the same business logic in this website in any other application (desktop, android, tablet, ewPhones, etc), then you have an alternative method.
Create your Busines Logic Layer as a different Project, and access it directly from your web app. When your Javascript (Angular/Razor?) Controllers make a call, they can call into your ViewModels and/or Codebehind or something similar, which can instantiate Business Logic and directly access it. No need for services if everything is right there and won't be reused.
Alternative 2
Go ahead and put your Web API ApiControllers in the same project. But, be sure you separate them into different folders from your MVC "Controllers." Still, when your Javascript Controllers make a call, they will be making Routing calls to your website for stateless returns. Do not mix the stateless ApiControllers with your ViewModels and other MVC code.
The downside to this is a lack of SOC. Now you have Service-Layer and UI-Layer mixed, and your UI-Layer is forced to access your Business Logic Layer (DLL). What's wrong with that if Alternative 1 did it?
Well, what's wrong is that Alternative 1 was a small application with no room for growth. Anything else (The original plan, or Alternative 2 here) should have UI's that have no clue whatsoever that Business Logic (or Persistence) even exist. They should go about their doodies unawares of the backend world.
I'm fairly new to VB.net programming. I'd like some suggestions for methods/procedures for sending real time data from a VB.net app to a web server (asp.net) for real time display. My question relates to the best method to send the data from the desktop app and the best way to receive and handle the data on the server. I'm not asking for sample code, just some idea of what methods to research. I am currently using a text file upload method but I'm sure there is a more efficient way of achieving this. Thanks in advance for your help.
For sending data to the server, you may research about webservice or WCF.
http://en.wikipedia.org/wiki/Web_service
http://msdn.microsoft.com/en-us/netframework/dd939784
For retrieving data from the server to your ASP.Net application, you can research about AJAX.
http://www.w3schools.com/ajax/default.asp
http://api.jquery.com/jQuery.ajax/
If you are using the MVC framework for ASP.NET (which I strongly recommend over WebForms), MVC4 which has recently gone into RC mode features a very nice new web API:
http://www.asp.net/web-api
"ASP.NET MVC 4 includes ASP.NET Web API, a new framework for creating HTTP services that can reach a broad range of clients including browsers and mobile devices. ASP.NET Web API is also an ideal platform for building RESTful services."
It allows you to define quite simple methods on the server which work directly with your actual domain objects and it does the work of returning data in an appropriate content type (e.g. JSON, XML) based either on the incoming request or a specific configuration you may set.
Your web app could then poll the GET methods on the same API controller class via Ajax (jQuery is nice) to display the results.
I have an application which I am currently writing an API. This is the first time I have created an API from start to finish and have read lots of good articles and how to do this. However a lot of that material focuses on the API development specifically (as it should) but have not found anything that touches on how to ensure the API doesn’t get broken by changes which happen within the application project.
My application consists of a ASP.NET MVC web app which makes calls to a Service Layer to undertake CRUD like operations. So to get a list of all the users in my app the MVC app calls the service layer and asks for them and is presented with a collection of users. My API (WCF Web API) also uses this service layer internally and when I request a list of users, again I get back a collection of users (JSON, XML etc).
However if for some reason another developer changes the underlying User domain object by renaming a field say surname to last name then this potentially is going to break my API as the Service Layer is going to return to my API a user object with a new field name when its expecting something else. My API does in fact have its own representation of objects which get mapped to the application objects when requested but this mapping will not map the surname property and will be returned as null.
Therefore do all changes in the app have to be strictly controlled because I provide an API? If so then do you have to change your app and API in tandem? What if changes are missed? The aforementioned doesn’t seem correct to me hence my post to seek greater knowledge.
Again I’m quite new to this so any help on this would be much appreciated.
It is inevitable that your application will evolve, if you can create new versions of an API as you applications evolve and support the older versions, then give notice of when older APIs will become obselete.
If you are owning the API design and you don't really want anyone to pollute your design. Introduce dedicate DTOs for your API use. Which be mapped from the underpinning domain models. But your presentation (via xml or json) won't change even underlying models change frequently.