Can a Breeeze ApiController support ODATA clients for read-only access, now that Microsoft have added ODATA support for WebAPI?
We are working on doing exactly this. Hopefully, we should have a release out with this ability within the next two weeks. I will post back here when it is available.
Related
I'm using identity server 4 as an authentication server, and have successfully demonstrated authenticating clients for access to my MVC web application and my Web API application, both running on IIS under .NET 4.7.
The problem I'm having is finding the correct approach for ensuring clients are only able to access the endpoints they should after the authentication process. EG, I have two clients, one with a write scope, and one without. How do I ensure the one without is only able to access endpoints that will read my data and not amend it?
The best method I've found so far is to use an authorization attribute like this:
https://github.com/IdentityModel/Thinktecture.IdentityModel/blob/master/source/WebApi/ScopeAuthorizeAttribute.cs
However, this is marked as obsolete and I'm unaware of the version based on OWIN middleware is mentions. Considering my MVC and Web Api applications are unable to be updated to .NET core applications, what would be the best approach?
Since the scope claims are available within the ASP.Net pipeline you can implement your own access control filter quite easily. It may be that that particular library is obsolete but the practice of enforcing scope in an MVC/WebAPI filter is certainly entirely valid.
I'd like to be able to have my BreezeController on the server side also be accessible by standard OData clients. I saw there was a question almost a year ago that was answered saying this was coming to breeze here. However, when I point an OData client (such as LinqPad or Excel) to my server it has an issue since the metadata isn't correct. This is even after changing the metadata action name on the controller to "$metadata". Am I correct in believing that a Breeze WebApi2 controller can act as an odata endpoint?
Hang in there, #cobywhite. We're about to release a Web API 2 OData sample that will show you how. Maybe by end of this week or top of next week.
You will have to make a small change on the OData server to get it to deliver the proper metadata. Are you able to do that?
As for reusing the "BreezeController" ... that's going to be tricky. OData is very particular about having its own controllers. I think you'll have to write those too. Make sure you don't put any business logic in any of your controllers. You shouldn't be doing that under any circumstances but now it will be imperative.
Always delegate to a repository or unit-of-work-and-repositories. The controllers should focus exclusively on their roles as vehicles and gatekeepers for communication with clients.
OData for WebAPI is rather ancient and doesn't support a lot of features WCF Data Services do.
I can't use WebAPI's OData support at all b/c of those too many limitations.
That makes breezeJS useless.
So the question is why is it 100% tied to WebAPI ODATA and is not a separate 'adapter' in the first place?
Most of the worlds' oData services are similar to WCF Data Services and not to WebAPI sub-limited support.
I don't want to carry 125 KB of useless code (WebAPI support that is) in top of the DataJS library when targeting WCF Data Services
I can't even use Breeze if saving through WCF Data Services is not supported!
When we will really have full support for WCF Data Services like you did for WebAPI?
As for question 2 there is a feature request for that at https://breezejs.uservoice.com/forums/173093-breeze-feature-suggestions/suggestions/3349980-full-odata-crud-support
Please vote if this is important for you too! (I did)
I have recently discovered OData & the new WCF Web APi library on codeplex. The web api allows me to expose results as IQueryable, which allows me to expose URL's in the OData format. Myn question is what is the difference between this and a regular OData Service, I read the following blog post http://phejndorf.wordpress.com/2011/07/15/wcf-web-api-odata-format-doesnt-mean-odata-service/ but I am unsure what the OP means.
Thanks
The WCF Web API supports adding a [QueryComposition] attribute to a function so you can use the OData $filter=.. style of filtering data on the server and sending only a subset back to the client.
With OData, I should say WCF Data Services, there is much more that just querying. You can do all of the CRUD operations. It also means you are using the OData, is an AtomPub superset, protocol where with WCF Web API you do whatever you like. OData is actually a hypermedia format that contains metada, relations etc.
I'm developing an ASP.NET MVC 3 application. I need this application to make use of an API I also need to implement. The API should both be available from ASP.NET MVC controller actions and Ajax. Now it is quite easy to make an API using ASP.NET MVC, but is it possible to use this from other ASP.NET MVC website actions? I guess the WCF is quite easy to use as it is just a service reference.
Other users of the API could be Windows Phone and iPhone.
Update:
Many only sees the API as a place where you consume data, but what about the part where you want to execute commands or do stuff, like add customer or change foo?
You may want to check our new WCF web API that was announced at PDC. We recently released a big upgrade. WCF Web API is designed specifically for allowing you to expose APIs to a range of clients in a pure HTTP manner. It is lightweight, offers a nice configuration story (no configuration files) and also is much easier to test.
You can download the bits at wcf.codeplex.com. It includes various samples, and there is also a set of NuGet packs for getting you started. Search for webapi.all on NuGet.
The way I like to do this is with RESTful controller actions. You can return JSON and use your calls with JavaScript on your own site. Other websites would almost certainly understand JSON and so they'd be able to consume your API pretty easily. This is much easier to write and test than a heavy WCF layer.
Check out this question for some example REST frameworks for MVC:
ASP.NET MVC REST frameworks
One of the newer ways of accomplishing data feeds is using OData. Scott Hanselman has a great introduction to it in Creating an OData API for StackOverflow including XML and JSON in 30 minutes.
It allows you to even throw LINQ queries into your URLs to retrieve exactly the data you need.
Open Data Protocol (Official site)
Open Data Protocol (MSDN, Microsoft)
WCF JSON binding was really terrible last time I used it. WCF also comes with all sorts of crazy rules about streams and how you have to use [MessageBody] attributes for everything.
It was a real PITA to me.
I knew I've answered something like this before:
What is the best way to implement a RESTful architecture in .NET today?