Monday, September 25, 2017

Is ODATA using Microsoft Web API really REST architecture?

Leave a Comment

The more I research about Microsoft framework on ODATA I tend to believe that it is not suited for enterprise application. The framework expects all the database to be directly exposed as ViewModel, even for simple operations like Pagination & sorting.

We would be forced to use stasteful mechanism to persist page numbers rendered to the JavaScript client.

Or am I not understanding Microsoft implmentation of OData correctly?

EDIT-1:

Is ODATA V4 a Stateful Architecture? As promoted by Microsoft patterns team. I do not see any easy path of Migration from Asp.Net Web API (REST) to OData (Sounds STATEFUL) Architecture.

EDIT-2: Paging, sorting & grouping is part of incoming request from the client.

1 Answers

Answers 1

In short the MS Odata server side implementation is not statefull and it can be considered a REST architecture.

We would be forced to use stasteful mechanism to persist page numbers rendered to the JavaScript client

You provide paging information in the request. For example, if you wanted 10 items of page 2 you would take the top 10 and skip 10.

odata-url/?$count=true&$top=10&$skip=10 

As you can see the client/caller specifies the paging, there is no need for the server to track state of the client.

Also adding $count=true will return the total number of records based on the passed in filter included in the result set (in the above example there is no filter). This will allow the client to calculate the number of pages there are.


The framework expects all the database to be directly exposed as ViewModel...

Also not true. You can return an IQueryable<T> where T is your type. T does not have to be an EF model. For example,returning the following from a DbContext is acceptable.

public IQueryable<SomeEntity> Get() {     return dbContext.SomeEntities         .Where(x => optionalPreFiltereExpression)         .Select(x => new SomeDTO(){             Prop1 = x.Prop1,             Collection1 = x.CollectionOfInterest,             // etc         }); } 

To further illustrate that point you could also return a hard coded list of objects, although this might not be very likely in production.

public IQueryable<SomeEntity> Get() {     return new List<SomeDTO>(){         new SomeDTO(){             Prop1 = 5,             Prop2 = "Hi there"             // etc},         new SomeDTO(){             Prop1 = 6,             Prop2 = "Goodbye"             // etc}         }).AsQueryable(); } 

There are many resources on all the options for OData. I am not going to include everything here, otherwise I might as well just be creating a 2nd set of documentation.

If You Enjoyed This, Take 5 Seconds To Share It

0 comments:

Post a Comment