$filter=Rating gt 2&$orderby=Price&$select=Rating, Price this requests all products with a Rating greater than 2, sorted by Price in ascending order, and asks the server to only retrieve the Rating and Price properties.
Servers may support retrieval of individual properties within Entries.
In addition to content-type negotiation clients and servers should use HTTP mechanisms for aspects such as character set negotiation (through accept-charset and content-type headers), caching and redirection.
Similarly, while this specification uses specific status codes for specific outcomes for a request, clients should be prepared to handle all HTTP status codes and interpret them appropriately.
Clients retrieve a feed, Entry or service document by issuing an HTTP GET request against its URI.
Servers respond with the feed, Entry or service document in the response body in the proper format.
Servers should map error conditions to HTTP status codes.
Common examples include using 404 (Not Found) when receiving requests against a URI not defined by this server, 400 for a general error in the request and 500 for a server-side error while processing the request.
Clients can choose to support only specific content-types or all of them.This document describes the operation model for the protocol, specifying the interactions between clients and servers for retrieving and manipulating data in an OData service.It builds on the [OData-Core] document for core concepts, [OData-URI] for URI conventions and on the formats specifications for Atom [OData-Atom] and JSON [OData-JSON] for the description of data representations.Atom feeds and Entries use a content type of "application/atom xml".However, when addressing Links or properties within an element the returned resource is just XML without the Atom Entry wrapper, and its content type is "application/xml".