Spring Data Rest Without HATEOAS

Question

I really like all the boilerplate code Spring Data Rest writes for you, but I'd rather have just a 'regular?' REST server without all the HATEOAS stuff. The main reason is that I use Dojo Toolkit on the client side, and all of its widgets and stores are set up such that the json returned is just a straight array of items, without all the links and things like that. Does anyone know how to configure this with java config so that I get all the mvc code written for me, but without all the HATEOAS stuff?

Dextrocular

Can't you map the REST response to the desired format? (late comment :D) – Yettayetti

Answer 1

After reading Oliver's comment (which I agree with) and you still want to remove HATEOAS from spring boot.

Add this above the declaration of the class containing your main method:

@SpringBootApplication(exclude = RepositoryRestMvcAutoConfiguration.class)

As pointed out by Zack in the comments, you also need to create a controller which exposes the required REST methods (findAll, save, findById, etc).

Fike

This stops SDR completely. – Pectin

This should be accepted answer. In addition to this annotation, you need to create a controller which exposes the required REST methods (findAll, save, findById, etc). – Scrivener

Getting quite a few downvotes for this, can anyone explain what their issues are after adding this annotion and creating their REST methods manually, wondering if this is now outdated or people are only reading half of the answer. – Fike

If you create controllers for exposing the required REST methods of your entities, what is the point of adding Spring Data Rest in the dependencies? Instead of adding this @SpringBootApplication(exclude = RepositoryRestMvcAutoConfiguration.class), it should be better to remove Spring Data Rest from the dependencies. – Sparerib

@Fike your proposed solution has exactly the same effect of just removing Spring Data REST from the dependencies. Really, try it. You are essentially turning SDR off. – Muttonhead

Answer 2

So you want REST without the things that make up REST? :) I think trying to alter (read: dumb down) a RESTful server to satisfy a poorly designed client library is a bad start to begin with. But here's the rationale for why hypermedia elements are necessary for this kind of tooling (besides the probably familiar general rationale).

Exposing domain objects to the web has always been seen critically by most of the REST community. Mostly for the reason that the boundaries of a domain object are not necessarily the boundaries you want to give your resources. However, frameworks providing scaffolding functionality (Rails, Grails etc.) have become hugely popular in the last couple of years. So Spring Data REST is trying to address that space but at the same time be a good citizen in terms of restfulness.

So if you start with a plain data model in the first place (objects without to many relationships), only want to read them, there's in fact no need for something like Spring Data REST. The Spring controller you need to write is roughly 10 lines of code on top of a Spring Data repository. When things get more challenging the story gets becomes more intersting:

• How do you write a client without hard coding URIs (if it did, it wasn't particularly restful)?
• How do you handle relationships between resources? How do you let clients create them, update them etc.?
• How does the client discover which query resources are available? How does it find out about the parameters to pass etc.?

If your answers to these questions is: "My client doesn't need that / is not capable of doing that.", then Spring Data REST is probably the wrong library to begin with. What you're basically building is JSON over HTTP, but nothing really restful then. This is totally fine if it serves your purpose, but shoehorning a library with clear design constraints into something arbitrary different (albeit apparently similar) that effectively wants to ignore exactly these design aspects is the wrong approach in the first place.

Inlaid

I would like to use HATEOAS on the backend, but I'm having trouble wrapping my head around how (or even if) this would work for something like a single page javascript webapp. SDR was attractive since it auto generated the controllers, handled paging/sorting, all that stuff, whereas with JSON over HTTP as you described it, I will have to write a bunch of controllers that translate things like content-range headers and query parameters into things a Spring Data repository can understand. – Dextrocular

Actually my whole point is: the server is just doing decent REST. If that breaks the client, it's the client that needs to be fixed (tweaked). So the hypermedia aspect is a fundamental one to Spring Data REST and we're not going to back out of that. That's probably not satisfying in your concrete situation but should answer the question at least :). – Inlaid

It is pretty unsatisfying, but yes you did answer my question. – Dextrocular

If you're looking for an example of a JS app running on top of Spring Data Rest checkout github.com/gregturn/task-manager-app. It has Spring Data Rest, Spring Boot, and even a custom Spring MVC endpoint serving an angular front end working nicely with the hypermedia. – Superjacent

@gregturn: do you realize that your sample DOESN'T use HATEOS and instead just uses hard-coded links? ))) – Erlond

Yes, but that is because the angular was written by someone else that focused a LOT of effort on building the controllers to handle all the ops. I was trying to demonstrate (in that case) how SDR can shrink your code base. My primary showcase all that uses hypermedia to navigate can be found at github.com/gregturn/spring-a-gram. Perhaps I should have led with that example instead. :) – Superjacent

What about things like AngularJS $resources. The Angular team explicitly says about it "($resource is) A factory which creates a resource object that lets you interact with RESTful server-side data sources." What is ironic is that HAL actually messes up the way Angular $resources act and makes them function poorly. – Disconnection

So you equating HAL with REST is honestly very confusing to me – Disconnection

Whatever Angular defines to be a resource is Angular's problem. If they consider a resource a "server-side data source" that's fine. It's just not REST. And the server library is called Spring Data REST, not Spring Data "Backend for Angular" ;). So you might run into trouble in case your client library fundamentally violates REST principles. That said, I have heard about quite a few Angular based frontend implementations that use SDR as a backend, so it doesn't seem to be fundamentally impossible. – Inlaid

The question shouldn't be "why should I use HATEOAS"? The question is "why should I use this implementation"? My company has had numerous problems with it and it's the #1 thing we gripe about when it comes to Spring. – Husky

I'm not sure I get the point. If the design constraints that Spring Data REST imposes onto your API design don't match what you want, don't use it. It's simple as that. If you're not using hypermedia, you throw away one of the defining characteristics of REST and thus the benefits you get from it. Doing so is just fine, you're just not building a REST API anymore and can't expect technology that wants to focus on that, align. – Inlaid

After consideration, I have come to the conclusion that the SDR authors are being overly dogmatic here. To use a metaphor, it is a bit like a situation where they are manufacturing a radio-controlled shovel and they will not create a mechanism that allows the users to remove the radio antenna, even though the users complain that the antenna really gets in the way when they are using it heavily without the radio control. Unfortunately the metaphor breaks down if you suggest that the users just adopt a different shovel for manual work. That is really not so simple with web services. – Pectin

REST does not mean HATEOAS or hypermedia. It's an approach to defining responsibility for rendering the data from raw source, and basically that's it. Even JSON is not something assumed by following REST :) – Ecotone

@altu – roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven – Inlaid

And I'll show you a blog post that I'm about to write how data and metadata should not be returned with the same response. HATEOAS is a waste of traffic and resources, both client and server side. Related entities managed with an ORM is for server side rendered (programs|websites|apps). Hypermedia is the SSR paradigm applied to CSR apps. You are wrong, you're just not "man enough" to admit it. One will want as little of possible and as much as necessary information returned from an endpoint. If Hypermedia was the solution is would've become an industry standard by now.Instead it's RESTful&grpc – Moncada

And I have to add that I mean no offence even if it might read as such. Such a popular and productive framework like Spring Boot, that it's missing options to Hypermedia. Hypermedia isn't the norm. It's one thing you're offering and insist to ignore every other option, "if you don't like it don't use it". Ok I won't use it. I'll continue using my generator written in Go, that is compatible with @ngrx/data as save myself a headache and some resources. – Moncada