Create your OData object: An easy solution to long REST request issues (2024)

If you use OData to query quite often in your project then you have faced this issue at least once:

- The length of your GET request passes the limits it has.

The URI limit is 2,083 characters. Any request with a URI length longer than this results in a 404 error.

This could be caused due to a filter with too many filter parameters, too many values to check against or a combination of both. We end up having this issue due to the fact that we didn’t think in those scenarios before.
Maybe our set of filters were more than the one we took into account when we started developing this area of the application. This could also be the case if the application process more information than the one it was prepared for or we just implemented a filter in a not very performant way.

A quick solution to this problem is to change the request type from a GET to a POST request sending the search query string in the body instead of sending it in the URI. As we will see after in this post, this is not the reason why POST is meant for, but is possible to use it for this specific cases.

But before we get to the solution, it’s important to know what REST and OData could be used for and why we can continue working with this approach.

REST, or REpresentational State Transfer, is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other. REST-compliant systems, often called RESTful systems, are known for its stateless and the way they separate the concerns of client and server.
(www.codecademy.com/articles/what-is-rest)

Due to REST leverages less bandwidth consume it is preferred over Simple Object Access Protocol (SOAP) technology for internet usage.
The REST used by browsers can be thought of as the language of the internet. As cloud use is getting more and more popular, APIs are emerging to expose web services. REST is the most appropriate choice for APIs creation since it allows users to connect and interact with cloud services. Sites as Amazon, Google, LinkedIn and Twitter consumes RESTful APIs.

A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data.

A RESTful API, also known as a RESTful web service, is based on representational state transfer (REST) technology.

A RESTful API fragment a transaction to create a series of small modules. Each of this modules represents a specific part of the transaction. We, as developers, gain a lot of flexibility with this modularity.

A RESTful API is based in the HTTP methodologies defined by the RFC 2616 protocol. Using GET to get back a resource; PUT to modify a resource; POST to create a brand new resource; and DELETE to erase it; we separate each of this modules.

In REST, networked components are a resource you request access in . All calls are stateless; nothing is retained by the RESTful service between executions.

Stateless components can be redeployed easily if something fails, and their scability help them to adapt in case of data flows changes. For this reason, any request can be directed to any instance of a component. Nothing need to be remembered by the next transaction. That makes REST preferred for web use, but the RESTful model is also helpful in cloud services due to its binding to a service through an API is a matter of controlling how the URL is decoded. Cloud computing and microservices are almost certain to make RESTful API design the rule in the future.

OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. OData helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc. OData also provides guidance for tracking changes, defining functions/actions for reusable procedures, and sending asynchronous/batch requests.
(www.odata.org)

That’s the definition of OData, but let’s dig a little bit more about it.

OData RESTful APIs are easy to consume. The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools.

OData consist of a set of conventions that can be layered on top of existing standards to provide common representations for common functionality. That’s why it’s power resides. OData supports server-driven paging. Appart from it, client-side paging it is also provided and we are able to query options such as Orderby, select, skip, top, filter, expand and inlinecount. This pagination is done on a per query basis.

As you can see, we are getting closer to the root of our issue.

You can use filter expressions in OData URIs to limit the results that are returned from a request. To add a filter to an OData URI, add $filter= to the end of the name of the published web service.
Here there are some examples how we can filter with OData. Those filters are not the only ones that we can use but it gives you an idea of what OData could be used for.

Now, that we have already have seen what this two technologies are meant for, let’s see how we can solve this issue.

For example if we have this REST call that gets all the Orders and it’s filtered with OData. My request consists of a dynamically built OData query including a potentially large number of ‘Field eq Id’ Or ‘Type eq “new season” ‘ filters which are captured into the ODataQueryOptions parameter which is then applied to the IQueryable database context.

Let’s use this code for example that I put all the methods together in order to make myself understood:

In this example, OrderWebService.GetQueryable method is getting the queryables objects that we are going to apply the OData filter options to in order to get the “order” objects that we are requesting.

This method is not relevant to the solution of this problem, but it is useful for showing how we continue using the same methods that we used for the Get operation.

First thing first, we need to send this query in the POST payload.

In this example, getODataStringFromReadOptions method will return the query filter options string. It should be the same OData filters that you were sending before.
Output example for demonstration purpose:

“$filter=((OrderType%20ne%20'New’%20CustomerId%20ne%201))”

Once we have finished with it and we are receiving this query on the server side, we need to choose between this two options, or at least, the most viable options:
- Use this query filter options to manually apply a filter, we can use LINQ for this.
- Create an OData object from the query we send.

In this post, we will only cover the second case. Since the set of pairs values(key-value) were not static but dynamically, custom filters were not a viable option. We are forced to go with the OData object creation.

In the GET rest request we are using this OData object that it was created by the request. As we are now using a POST request, this object is not created automatically. Therefore, we need to mock it. For that we need to proceed with this steps:

• Create new Post Method that receives the request in the Order REST Controller

• Create the filter OData object that we need (filterQueryOptionOdata)

• Use the object we created ( filterQueryOptionOdata), instead of orderQueryOptions.

Finally, this is how the Post method should look like:

Working this way has this advantages:

- As we are re-using a search engine we know how it works we are getting the same results as before, making it easier to test.
- We are not wasting time trying to create a new controller for this new scenario.
- We avoid entering new bugs to the solution since it’s a preexistence code.

As I mentioned above, this was the best solution that we found for this problem but is not the only one. Hope this information helps you!