1) What are the advantages of HATEOS compliant RESTful service?
There are three roles at play here: server, user-agent, and user. Let's take this web application as an example. We make HTTP requests to the "server" and get back HTML/etc responses. The web browser is the "user-agent" that hides the HTTP/HTML/etc complexities from us and provides us afforances like links and forms to interact with. The user-agent is more often referred to as the client. You and I are "users".
One of the things the REST architectural style gives us is the decoupling of client and server. The client in this statement is the user-agent (think web browser). StackExchange can update their site without us needing to update our browser. Browsers can be updated without StackExchange needing to update their servers. As long as the two are speaking the common language of HTTP/HTML/URI/etc, each can evolve independently. This common language is referred to as the Uniform Interface.
In the context of REST APIs, it's not as straightforward which elements play which roles. The server is still the server. The user-agent is usually an HTTP client you use to make HTTP requests to the server. The user is the application. That's a strange thing to say, but it's important to understand the benefits you really get from hypermedia (HATEOAS).
The reason that getting the same evolvability characteristics from APIs as we get with the web is so elusive is because users of the web are humans and users of APIs are programs. Humans can easily adapt to a moved button or a new workflow. Programs have to be updated to deal with most changes.
However, that doesn't mean that hypermedia isn't useful for APIs. Usually, we interact with APIs through HTTP clients. Just like with web browsers, we can choose any HTTP client we want and it will work with any server that speaks HTTP.
One problem with this is that programmers need to be proficient in a dozen or so web standards in order to use the API. So, what we end up doing is creating wrappers around the HTTP stuff making functions that programs can call for doing all the things the API can do. Without hypermedia, those user-agents necessarily have to be coupled to the functionality the server supports. If the server adds a new feature, the user-agent needs to be updated to support that function.
Here is where hypermedia comes to the rescue. If the way your app does state transitions is encoded using hypermedia and included with the resources returned by the server, the client doesn't need to hard code those points of interaction anymore. If your programs interact with the user-agent by following links, adding a new feature to the API doesn't require any changes to the user-agent. It does however require the program (think user) to be updated to make use of the new feature.
Imagine if you had a user-agent that was generic, but felt like it was tailor made for your API. It abstracts all of the technical details of HTTP and media types so it's really easy to use. You can use the same user-agent for multiple APIs. You could even link from one API to another and the user-agent would handle it as smoothly as if it would if it was the same API. This is the kind of thing that's possible with hypermedia.
2) What does it take for a developer to redesign any application, as HATEOAS compliant? In order to perform functional testing successfully.
I use JSON Hyper-Schema to do just that all the time. Hyper-schemas are like templates that you can apply to plain JSON to add links/forms to your JSON. You can use a
Link header with
rel=describedby on your responses to indicate a hyper-schema to apply to a JSON response. One of the benefits of this approach is that you don't have to change the JSON to add hypermedia. It's completely backwards compatible with any JSON API.
I'll often create a simple proxy server to add hyper-schemas to plain JSON APIs I'm working with. I can then browse those APIs with Jsonary. Jsonary is a user-agent that can create a user interface given a JSON Hyper-Schema API.
Here's an example of a TODO List API running in the Jsonary browser. http://json-browser.s3-website-us-west-1.amazonaws.com/?url=http%3A//hypermedia-todo.herokuapp.com/. It's not the prettiest interface, but you should be able figure out how to use it with no documentation. Just follow the links and fill out the forms.
There are some limitations to adding hyper-schemas to a plain JSON API. Because a hyper-schema is like a template on the JSON, you can only express links for things the JSON has data for. Take paging for example. If I'm on page 4 and I want to provide a
next link to page 5, I can only do that if the JSON includes the information that the next page is "5".