I created a Web API with .Net Core.
I currently have the form from the .cshtml page posting through to a normal MVC controller and then using the HTTP Post method to post to the Web API endpoint.
Is it better to post directly from the form on the .cshtml to the WebApi endpoint?
I'm relatively new so not sure which is better.
Imho the current approach is correct: you post some data to a controller inside your application and then do stuff with this data (in this case sending them back to a Web API).
Why is correct? Because you can do all sort of checks inside the controller before sending any data to the Web API (like data validation, transformations, composition etc...). Also, I'm not sure if you can post directly to a Web API using Blazor methods for posts. To do that I think you have to write the form using plain HTML and than detect the submit event using Javascript, where you finally post the form data to the Web API. But again, I think the current approach is good (if not optimal)
it's not a bad solution by any means but if your API is publicly accessible (not just from your web project with the mvc controllers) I would suggest posting directly to the API.
Posting directly to the API reduces roundtrips. And also the validation and everything should be handled by the API.
Use Web APIs when you want to deal with data or HTTP status codes only, i.e. not expecting HTML to be returned. Typical use cases from a web perspective are doing any asynchronous communication through Javascript (native JS, Vue, Angular, React, JQuery, etc....)
If you expect HTML to be returned, use MVC or whatever view framework you want to use. In this case it is perfectly fine to call other APIs from the MVC controller.
Related
At the company I work at we have a couple of different services
API (.NET Core)
Internal Frontend (React)
External Frontend for customers (React)
I was asked to create some views which will be converted to PDF's by an API, but I can't decide where to put them as they are not related to our Internal- or External-facing projects.
My first thought was to put them in our .NET Core API. However this has previously been a strict json-only API, so I have an itch that this is not the intended use.
So internet, my questions are as follows
Is it a big NO-NO to put Razor-views in our API?
Should I dedicate a microservice to this?
What is best practice?
Thanks in advance!
You're right, Razor views will be excess. I see two options:
Backend: Create an endpoint which will return a PDF file based on passed data. Of course you can expand data. This way is similar with Razor: you have a view model and render it to PDF file. An example of library: iTextSharp.LGPLv2.Core
Frontend: Convert HTML to PDF on client's side. Something like react-pdf
I prefer first option, because, first of all, there is already an option "Save as PDF" in browsers, so it will be some kind of duplication of functionality. And on the other hand back-end PDF generation seems more flexible (you can use all of your domain and you can create independent layout either) and you can organise some kind of file cache.
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.
I'm going to be developing a new system and am toying with the idea of either creating a single page application or a full asp.net mvc website.
I want to utilise knockout so if I went down the mvc route i'd need to load my mvc view and on document ready then make the ajax call to bind to my knockout view model.
Is this a bad approach as i'm effectively making 2 calls to get one page?
Depends really on your exact page design and behavior.
But generally MVC and knockout do not require you to get the data via ajax, you can populate your data from the server then manually apply bindings to your observables.
saving the data could be done via ajax.
Of course its all theory now, you need to see your screen designs and check which way to go.
I have been working on a Web API which I am hoping to be RESTful. To give an example:
http://product.domain.local/person
would give a a web page with a nice UI served by ASP.NET MVC (for humans).
However, if I ask for Accept json/xml in my HTTP header, I'd like to redirect the request to my Web API controller. ie. as well as MapHttpRoute, I want to map based on contentType requested.
Therefore, when my API returns an ID:
http://product.domain.local/person/1
If a human uses it, they get a web page, if a client application uses it, they get JSON/XML (because they'd modify the Accept header), which allows me to use HTTP redirection, etc. to work towards REST.
But I can't find a way to do this. Is it even possible?
I've found this to be quite difficult. Webapi is really good at routing based on the accept type header, but isn't good at dealing with views. MVC is good at views but not as good at handling various responses.
If anything, I think it is easiest to make MVC is easiest. Depending on the flexibility you need for the accept type handling, you could probably just implement a common function (that returns an ActionResult) and in it just return the proper type based on your head (or anything else you would like).
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.