Spring Data REST vs OData

I have a few questions about the concept of Spring Data REST as an Enterprise-capable data access tool.
Spring Data REST looks to effectively expose Spring Data repositories. But, it looks like OData and OData4j have gone farther so far with their exposure of JPA and InMemory Producers accessible via ODATA URI constructions sent as REST URL parameters.

Complicating the above are articles about the sanctity of REST and whether it is properly used for CRUD-style access to data. And in Daigneau's "Service Design Patterns" we learn about the problem of exposing database implementation details to the client.

Here are some questions:
1. What will be similar and what different between the vision for Spring Data REST and the present OData?
2. Ignoring security concerns for the purpose of this question, under which conditions is it desirable to allow generic access to a data repository where arbitrary selection/projection queries can be formulated from a client? When is it not a good idea for the client to make this formulation?
3. For cases where generic access is desirable, should clients ultimately have full JPQL-style query powers? If so, how can exposure of database implementation details be avoided?
4. For data that is complex and needs to be enriched and complexly structured, Moxy, for instance, could be used to create the necessary mapping on the server side. How might Spring Data REST be addressing or complementing this problem space, if at all?
5. OData addresses authorization and authentication. How might Spring Data REST be addressing these?

Thank you.

Trying to catch these questions from a SpringData point of view.

1. The OData protocol exposes data (as the name suggests). With Spring Data REST we hand you means to expose entities managed by a repository as REST resources. The are two different crucial differences here: first, for some reason OData is doing things RESTish but not really. It talks about entities and services and such. It feels like it felt REST was missing something and they'd had to reinvent basic concepts. Just read the documentation section on "addressing actions":

Quote:

---

The actionCall syntax rule defines the grammar in the ResourcePath for addressing and invoking an action directly from the Service Root.

---

Not speaking for the entire team here, but that just feels like yet another SOAP. We're taking it from the REST angle: you have resources, URIs, links, representations and provide you with simple means to expose entities and - to me more specific - aggregate roots (which are managed by repositories) define natural boundaries of what will be manipulated. We don't think it makes sense to expose every property of an entity. So we'd rather like to stick to the boundaries the domain defines in itself. We're not exposing the entities as such but create default representations but enriched with hypermedia means that allow you to discover the API and extension points to hook in custom functionality (see below).

Long story short: I think Spring Data is a more pragmatic, more hypermedia driven, less spec and data centric way of implementing REST webservices. OData is a data exchange protocol. We're coming from the REST/Hypermedia point of view, OData takes it from the data.

2. We're not providing generic access to data here. We expose resources that you have absolute control over what can be done with it. Understand Spring Data REST as taking away the boilerplate from building REST web services that would mostly expose a representation of the entity enriched with basic hypermedia. You're still in charge fo customizing representations, adding links etc. We also don't expose the means to query data arbitrarily but rather expose predefined searches as a resource. This way you implement the actual query semantics at the repository level and only expose query parameters.

3. See 2.

4. Our approach here is: everything this makes up an aggregate is included in the representation, everything else is linked to. This can definitely take different shapes for different stores. For JPA, pretty much every relationship will rather be a link than an inline rendering. MongoDB on the other hand can expose embedded documents as is.

Another aspect to this is that the repository exporter provides an extension mechanism you can use to enrich the hypermedia aspect of a representation programatically and thus link to manually implemented resources outside of what is exposed by default. Take the RESTbucks coffeeshop (from the REST in practice book) as example. You could definitely expose the Orders using the rest exporter but manually implement the payment resource and register a ResourceProcessor<Order> with the exporter to add a links to the Order representation to the payment resource in case the order has not been payed yet. This is a crucial step to avoid not doing plain CRUD via HTTP and allow HATEOAS REST services but taking away the boilerplate.

5. Currently only by integrating nicely with Spring Security. You'd simply set up the appropriate intercept rules for the resources exposed in your SpringSecurity configuration and take it from there. We're in close contact with the SpringSecurity team to tighten the integration at that point (e.g. allowing the usage of @Secured right at the repository interfaces).