If I perform all my operations (add item to cart, check out etc) by calls to controller methods that return JSON to my knockout.js presentation layer, can my application be considered restful?
Not really. There is nothing available to respond to HTTP verbs other than GET and POST. If you want you can use an ApiController class This is designed as a restful controller.
Related
There is a sales service implemented as a Telegram bot. I need to create a website control panel for this service. Since the service is a .NET application I am thinking to use ASP.NET Core technology.
How do I transfer data from the controller action to the Program class containing all the functionality of the service (maybe it is worth defining the Program as a static class)?
You may have misunderstood Asp.Net Core. .net core adopts the pipeline mode, that is, when you call the action in the controller, it will enter the middleware pipeline of Program.cs(.net 5 is Startup.cs), and execute in sequence according to the order of your middleware, adopting the principle of first in, last out. This means that if you follow the normal .net core logic, the value you get in the controller (except the parameters defined in the URL), you cannot pass it into Program.cs. When you successfully enter the action of the controller, Program.cs has been executed.
Not sure what your sales service looks like, but I think you can register it as a service and use it in your controllers using dependency injection.
Helpful link: ASP.NET Core Middleware.
Why do i need to inherit from Controller to return JsonResult?
What is the mechanism that makes the JsonResult type available?
I've tried thinking on it and I figure maybe Controller declares it as a type, but I don't know.
You will need to inherit from Controller in order to use the Controller.Json utility method. You will however not need to inherit from Controller just to create a JsonResult. You can always just new-up one. As long as you are within a controller (not necessarily one that inherits Controller), this will still work:
return new JsonResult(object);
As for why you will need to inherit from Controller and not just ControllerBase; many of the result utility methods actually live in Controller. The reason for this is that those are targeted to view-centric controllers while ControllerBase is typically used for API controllers.
Now one would think that returning JSON results would be especially useful for API controllers but that is actually not the case: For API controllers, you should rather return an ObjectResult and have the conventions take care of serializing that into the format that was requested by the client. That way, an API controller can easily support formats like JSON and XML at the same time.
Is it possible to call WebAPI endpoints without extending the Controller base class? I have a background service (base class HostedService implementing IHostedService) in .Net Core. My class structure is already set in stone so I can't change the base class of my background services. But it would be a huge help if I could call url endpoints on them without actually having a separate controller.
Is this possible?
EDIT: My background services look exactly like this.
Why don't you use something similar to ValuesController in the link you provided?
You only have to create a new Controller with almost any logic, just calls to your Hosted service.
Is HttpContext.Items still considered a reasonable place to share things between different parts of a request? Particularly HttpHandler's outside of MVC, like WIF extensibility points.
How do you access this dictionary from within MVC4's ApiController? Without using HttpContext.Current static methods (I still want it unit testable). The normal controller had HttpContextBase/Wrapper which abstracted it a bit for testing.
Use Request.Properties inside the Web API Controller.
When implementing an ActionFilterAttribute it's filterContext.Request.Properties
I’m aware that not everyone uses a thorough architecture when developing an MVC application but let’s assume I have the following architecture:
App.Core --> Class Library (POCO or Domain objects)
App.Data --> Class Library (Repository and Entity Framework)
App.Service --> Class Library (Service layer with all business logic)
App.Web --> asp.net MVC 3.0 project
App.Data --> Has a reference to App.Core
App.Service --> Has a reference to App.Core and App.Data
App.Web --> Has a reference to App.Core and App.Service
Inside our MVC application we try to follows this approach:
Inside our Controller (within a method), we instantiate a ViewModel.
We fill that ViewModel calling methods from our App.Service Layer
Once the ViewModel is filled, we return it to the View (so the view
is now strongly typed).
This occurs 99.9% of the time. It is clean, we like it and it leverages itself pretty well..etc!
Now my question is the following:
If we decide to move our application to MVC 4.0 and start using the
new Web API approach, I’m not sure I fully understand where (or how)
it would fit in our current architecture?
Keep in mind, that we are open to change this around!
Should we create a new App.WebAPI layer that sits between the App.Service and App.Web?
This means inside our Controllers, we would no longer need to call the App.Service directly but instead the new App.WebAPI layer?
Or, leave the Web API inside the App.Web layer and make the Controllers call the other APIControllers which in turn would call the App.Service layer?
Not sure if I make any sense here…but please feel free to suggest anything as I’m curious on different inputs.
Thanks
There are a couple of cases to consider:
Do you want to make this Web API serve as service layer and data access for your MVC application? If, yes, then you should completely remove all references of App.Service from the ASP.NET MVC project and have it query the Web API instead to fetch the data. In this case the Web API sits between your ASP.NET MVC application and the data access. It is the Web API that talks to the service layer and exposes it over the HTTP protocol.
Or do you want to provide an additional API for your web site that can be used by other clients (other than web browsers)? In this case the ASP.NET MVC application and the Web API sit on the same layer. Both query your Service layer to fill view models, it's just that in the case of the MVC application you are passing those view models to views which in turn convert them to HTML whereas in the Web API layer you probably use slightly different view models but which are still populated from your service layer and are passed to the client used the corresponding serialization mechanism (JSON, XML, ...)
I know this is late but I was actually looking for the same advice and I found this post.
Wouldn't having "both the MVC and Web API sit within the same layer" mean more maintenance work on the code, or maybe duplication of code? isn't the mvc web considered as a browser client? .. to me it makes sense to have the WebAPI your only layer to everyone else and in turn it would call your service layer for processing.
What is the benefit of leaving both the Web API and the MVC talking directly to the service layer? Can't the web API be the wrapper around the service layer?