I have built a few WebAPIs since it was born, including one supporting OData URL filters when that was new. I see now that OData over WebAPI has matured, I see it can serve service metadata.
Is it complete enough for Excel or other OData client tooling to plug and play as if it were a full WCF Data Service (ye olde Astoria)?
That's it. Thanks
OData V1-3 services can be consumed by the Data tab and Power Pivot data source import of Excel. While Excel's support for importing data from OData V4 services will rely on Power Query. That support is planned targeting early next year according to this: https://social.technet.microsoft.com/Forums/en-US/2169958f-9e2a-4fc2-a844-c0dce4c17a19/support-of-odata-v40?forum=powerquery
It is. In the past you had to do the right configuration or do a workaround to populate the OData feed from Web API correctly, to be able to consume it from Excel. Suprotim Agarwal wrote an excellent blog post about all the steps necessary to consume the feed from Excel, including creating and configuring the endpoint and what the steps in Excel are.
Related
I have an ASP.NET Core 5 Web API that communicates with a SQL Server database using ADO.Net using stored procedures. This API is consumed in another ASP.NET Core MVC project within the same Visual Studio solution.
What is the best and most reliable way for the MVC project to handle pagination, sorting and filtering functionalities for the displayed results received from the Web API project?
Fully functional source code: https://github.com/krchome/WebAPICoreMVCClient
Regards,
Kaushik
When you design an API project separately, the idea is that you will keep all the logic and data fetching activities like sorting, filtering, and paging in the API itself. This makes the API self-contained, cleaner, and faster. UI will be responsible for sending the required parameters to the API which includes page no, sorting key, etc to the API and API will give the correct data. which you can consume from the UI and show it.
Around a year ago I made an iOS application that finds restaurants near your location of any type and displays information about them. I made a web service call using the FourSquare api to get all the data which was returned in json format and then I parsed it and displayed the information on the UI of the app. Now I want to make an android application using Xamarin.Android since I am learning working with Xamarin studios and C#. When I make a Xamarin.Android application and go to packages then add packages I see there is a Foursquare api package that has a .NET wrapper around it. Here is the website url:
https://www.nuget.org/packages/Foursquare.Api/
So my question is how does this work? Does adding this package mean I don't have to make a web serivce call anymore, instead all the data is stored inside this package and I just have to get all the data the same way I get information from a local database? What are the advantages of using this package instead of just making a web service call to Foursquare?
Think of it this way:
This Foursquare API is simply a .NET wrapper of the web service that you want to use. Thus, somebody has gone ahead and done all of the hard work for you so you can simply consume the returned data in your applications.
What does this mean for you?
Well it means that you don't have to write any REST consumption code and you can focus more on the actual application and any business logic that you need to implement based on the Foursquare objects.
To not confuse any further, this data would come the same way as if you wrote your own web service to access the data from the Foursquare API endpoint.
Advantages:
Already written for you
You don't need to know your way around their REST API
Usually follows best practices per language so it's easy to consume (Objects created, methods, etc)
Disadvantages:
REST endpoint might be updated and not reflect in the package until it's updated
Any bugs/issues in the framework can be hard to workaround if the project is not open source
Could be a lack of documentation on how to use the wrapper
I would like to expose the SQL Server Views via OData Web API but I don't want to create separate controllers for each views as there are too many of them and they will only accept GET verb for all the views.
I thought I can achieve this using BreezeController but it looks like I cannot as it is obsolete now (The package which has BreezeController attribute is marked as obsolete).
Is there any way to achieve this with OData Web API that works with BreezeJS?
The [BreezeController] attribute is not obsolete. In fact, it is central to the "happy path" Web API controllers you see in the Breeze samples. I wonder what lead you to think otherwise? What package are you using?
I'm referring to the ASP.NET Web API!
The ASP.NET Web API OData is a different matter. Despite "Web API" in the name, that is almost a completely different approach to server development with its own behaviors and wire format. It does not use the [BreezeController] attribute and never has.
I'm not sure what you meant by "view" in your phrase, "separate controllers for each view". I think you mean what I would call "type". For example, in OData you'd expect a "Product" endpoint for your Product entity type.
AFAIK, the Web API OData approach demands a separate controller per type. That's what Microsoft's Mike Wasson says in his tutorial. He writes ...
A controller is a class that handles HTTP requests. You create a separate controller for each entity set in your OData service.
BreezeJS supports Web API OData too ... although there are limitations imposed by the current Microsoft implementation that may give you pause.
We are working through these with the OData team and hope to have better news in the coming months.
Here's my situation, I'm trying to create a WPF application that connects to my own web odata service (uses web api and entity framework). I have my own set of domain models/entities in the server side that the web api and entity framework works with. When, I add the web odata service reference in the WPF client side, it can't recognize my own domain models/entities and it looks like it creates its own set of it. Is what I'm trying to do even possible or am I just missing something?
Regards,
Raymond
Drive-by answer (unchecked): I remember reading that it wasn't possible at least a few weeks back. You might want to search the Uservoice site and the official forums for current status, or wait for a better answer here.
It looks like this problem is currently a feature suggestion for WCF Data Services (thanks to tne's uservoice link). The direct link to the request is https://data.uservoice.com/forums/72027-wcf-data-services-feature-suggestions/suggestions/3220086-allow-re-using-entities-from-another-dll-on-the-cl.
I have read this document "http://jaydata.org/blog/how-to-use-jaydata-with-asp.net-web-api---i" and it shows a very clear and simple way to user web api odata, but in this example, all the data types are defined manually, and I read the words from the document
"The ASP.NET Web API provider does not use server generated metadata to setup the client. You need to provide the JayData library with some information about the data types your about to deal with. This at the moment you can only do manually. Version 1.2.7 of JayData brings Visual Studio development time support for autogenerating the client environment."
Currently, the version 1.2.7.1 is released, but I can't find any information that how to use some tools from jaydata to auto generate these data types.
Is there any document for this?
Yes, we promised it and we did a proof of concept but nobody has asked about it since that post, you're the first, so we think that our current users are happy with either creating the model manually or using WebAPI with oData where the model can be built either dynamically from $metadata or statically with JaySvcUtil.
I can not promise any date when we'll release it.
Can't you just use WebAPI with oData ?