We are planning to use oData as a entity standard for rest api layer. The data provided by web api are taken from various subsystems and layers of cache(memcache) involved. My fear is how the basic entity model without EF can support the oData implementation of pagination and filtering. I want the ability to restrict the retrieval record limit at the underlying susbsytem level not at the api controller level. Any pointers would be useful. Thanks.
I have written a blog post on doing OData querying over non-IQueryable backends. I have picked HQL as the target query language. http://blogs.msdn.com/b/webdev/archive/2013/02/25/translating-odata-queries-to-hql.aspx
That should help you to understand how easy it is to support OData queries using web API.
Related
so i have a spring boot application and my data source is MySQL via JPA. I am trying to introduce Odata queries to my API's and then fetch data based on those odata params. I was wondering if there are any utils or external libraries i can use to parse the odata query then construct the JPA Specification. I have looked into olingo but im not sure if it is exactly what i am looking for. I was thinking of parsing the query text, and constructing the jpa specifications manually(maybe use reflection is necessary), but if anyone has any tips or advice on how to better approach this it would be much appreciated!!
I was thinking of doing something similar to this but with odata instead. Only issue i see is making this dynamic enough to handle every complex odata query coming in.
https://www.baeldung.com/rest-api-search-language-spring-data-specifications
I have written a apicontroller class that supports ODATA by using the EnableQuery attribute on the methods and returning the data asQueryable. It alls works fine for me.
What use is the ODataConventionModelBuilder? Do I still need to use it?
The using of ODataConventionModelBuilder enables
The mapping from your POCO classes to the OData model including handling primitive types, complex types, entities types and relationships between them, actions, function, and so on.
It also helps validate if you have a correct OData model.
It helps set up the metadata document and service document.
If you really want to expose an OData service that conforms the OData protocol, you would need to do a lot yourselves without the ODataConventionModelBuilder. But if you don't care about things like conforming model conventions or exposing the service model to the service consumers, you may not use it.
I’m thinking of using OData for my web service (based on Web API). Unfortunately, my datasource is NOT IQueryable. Instead of implementing my own IQueryable I pretty much followed this blog post.
What I don’t understand is how to get to my entity data model (EDM)? Do I have to model an EDM for example in the Designer? Or is this for EF only and I can use „plain“ classes instead and set relation-attributes? I don’t want to expose my internal data structures therefore my EDM is more like DTOs...
In an example I’ve seen that I‘m supposed to derive from EntitySetController in order to get the OData-compliant HTTP response. I believe I can’t use EntitySetController as I don’t support IQueryable. What am I supposed to do in order to get a proper response anyway?
You can build an EDM model yourself. You can use the ODataConventionModelBuilder class to build your EDM model. This tutorial has some sample code.
Also, checkout the samples on OData from here, especially the ODataServiceSample and ODataCompositeKeySample. They should get you started.
Also, if you do not have an IQueryable, you could derive from ODataController instead of EntitySetController.
If I need to build a web application that implement functionalities related to managing an Medical hospital institution. That application include functionalities to add, update, delete, search and retrieve patients, medical visits, etc.
So I am confused on which approach to follow inside my ASP.NET MVC web application, either to have my controller classes inside my asp.net MVC.
Derived from IController to perform the CRUD operation
OR
Derived from ApiController to perform the CRUD operations
SECOND question is there an approach that is taking over the other, and what are the advantages/disadvantages of each approach over the other?
You can absolutely use both. Nothing stops you to use good old Controller to do CRUD in JSON and MVC is capable of doing it. However, you do not get all the nice features of Web API such as content negotiation, message handlers, media type formatters, etc.
If you do not need any of Web API specific features, then use MVC. But on the long run, Web API will be a better investment as I believe adoption will rocket soon.
If you are going to generate classical HTML pages from your controllers, use the MVC ones. If what you want to return to a client is some kind of serialized data (XML, JSON, ...), use Web API controllers since these make it easier, regarding e.g. content negotiation.
See also Getting started with Web API
I am creating my first ASP.NET MVC 3 application, and my data comes from a data source I can access only via its REST API.
I will only be using READ-ONLY access at this point to the REST data source (no updating, etc.)
I would like to use the Entity Framework V4 to provide a Business Entity interface to MVC 3 without exposing it to the REST API.
I need to get something working quickly - so I don't have time to fully understand the Server Layer / UnitOfWork and Repository patterns just yet, although I plan to go there next.
I am willing to use a Repository class at this time, but not ready for DI / IoC container yet.
Any suggestions on where the RESP API calls go?
EDIT
Learned by asking this question that it is not necessarily useful to integrate an ORM with a REST API - See my accepted answer below.
An Object/Relational Mapper, or ORM, like Entity Framework has specifically been developed to abstract away a relational database. It might not be the right fit for REST calls.
You could instead build a repository class that encapsulates the REST call and exposes methods like IEnumerable<T> GetAll() or T GetyById(...).