Hot answers tagged

37

I think your instincts are largely correct; those proclaimed benefits really aren't all that great, as for any non-trivial web application the clients are going to have to care about the semantics of what they're doing as well as the syntax. But that doesn't mean that you shouldn't make your application follow the principles of HATEOAS! What does HATEOAS ...


8

the app we are building won't simply look at the links and then by itself render the correct UI and make the right ajax calls In fact, this is exactly what HATEOAS will give the UI. Not what is possible, but when it is possible. A formal HATEOAS like HAL, as the question states, gives links that indicate what is possible. But when those links show up ...


8

The need for discoverability may not be relevant, but the links that allow discoverability serve more purposes. The most important of these, to my mind, is that providing full URI's in the responses to the client, means that no client will ever need to "compose" an URI. That means that no client will ever need knowledge about how the URI's are structured. ...


5

The things is, HATEOAS must come with a second pillar that define what a RESTful API is : standardized media type. Roy fielding himself said A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources". With a standardized media type that define the transition explicitely, and hypertext to ...


4

"Clients" may not be advanced enough to make use of it, but the users of clients can. A client can be something as simple as a web browser, after all. The discoverability is all about enabling people to learn and use the API. For example, Jenkins (the CI server) has a REST-like interface. Go to any page, postfix the URL with "/api", and you get a page ...


4

NOTE: I'm no expert on the subject, but I went through a similar process of trying to reconcile the different nuances of people's interpretations of "REST" a few years ago, and this is the takeaway I got from looking into it at the time. To my understanding, this stems from Roy Fielding's Hypermedia as the Engine of Application State aka "HATEOAS", which ...


4

You can publish details on your services through a "WADL" http://en.wikipedia.org/wiki/Web_Application_Description_Language It's optional and not every backend REST technos supports this. Jersey, the "official" java implementation of jax-rs, supports it for example - it can be automaitcally generated for you. It's quite rare though, to see it used. I ...


3

HATEOAS is a somewhat controversial topic. Many people feel it's an example of overengineering and see no practical benefit to it. I believe it offers a natural and sensible approach to implementing Web APIs, with the benefits of increased decoupling between server and clients and a lower burden on client developers (see my answer to "REST HATEOAS - How does ...


3

what is expected to live at the endpoint represented by that URI? A resource of some kind. Generally, you can identify the type of resource by examining the mime type. Often, it's just a web page. How is http://schema.org/name less ambiguous than name? It lives specifically at the http://schema.org/ domain, and the domain itself is unique. In ...


3

I had the pleasure a while ago to work with an API that had documentation that was very, very hard to understand. Once I managed to get an actual reply from the server, it was possible to compare the documentation with the server reply and use that to decipher the documentation (and yes, deciphering it was the right term). The problem was that if a request ...


2

These codes follow the standard set by the HTTP rfc. According to the Status Code Definitions section: 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. 403 Forbidden The server understood the request, but is refusing to fulfill it. ...


2

As you pointed out, Roy Fielding wrote an interesting article on his blog. And this paragraph summarize pretty well "How to HATEOAS": A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-...


2

Disclaimer: answer offered without first rereading the Fielding thesis. HATEOAS supports the discovery of previously unknown application states. Think state machine. The hypermedia representation sent to the application describes a current application state, and it describes which triggers are valid transitions out of the state. It doesn't necessarily ...


2

In the case bellow, no it should not be updated (then again is a uri to close account restful ? or withdraw money ?) class BankingAccount() { Double totalAmount; String ownerName; URI uriToCloseAccount; URI uriToWithdrawMoney; } Suppose this is your model: { "links":{ "self": "/accounts/ACCOUNT_NUM" "owner":"/customers/...


2

As I currently understand HATEOAS is basically all about sending together with each response links with information about what to do next HATEOAS is a lot more than just links. It is "hyper media" as the engine of application state. What is missed in your description is the content type, the formal definition of the hyper media that is passed between ...


2

You don't have to build a dynamically generated interface. Though it could be nice it's not required. If you cannot build a dynamic interface just use the links and you are done. Disadvantage is that you are again hard linked to the backend and will crash if something changes. Using the dynamic layout can be quite simple btw: links.forEach(function(link) { ...


2

what would be wrong with treating a client session as a resource/an application state as well? There is nothing wrong with that per say, the problem comes when you try and use application state (in the form of session resources) as a form of authentication. You are basically saying that if the application is in this specific state then this client (say ...


2

what would be wrong with treating a client session as a resource/an application state as well? The short answer is that you get unexpected side effects when the client's understanding of application state and the server's understanding of application don't match. Review Fielding: Section 6.3.4.2. Notice that, in the examples that you describe, the ...


1

Sessions are temporary data needed by an application, and are usually orthogonal to what the API is doing. Adding session management in the API distracts from the core functionality, and could introduce unrelated bugs. The best place for session data is in the application itself. However, there's nothing to say that you couldn't make a separate API to ...


1

Your second approach—including in the job model only links to actions the user is actually entitled to perform—is the one I would take. It keeps the focus on the resource and the actions that can be performed on it, which makes it both relatively simple and a good fit conceptually for the REST architectural style. It retains on the server all ...


1

In REST, do we always use link relation values to convey semantics/role of a linked resource? Using link relations is just one way to add semantics to links. The other standard solution to use RDF vocabs, for example hydra or schema.org. I assume link relation value is always specified using rel attribute? This depends on the media type, for ...


1

Spring has some support for this as does resteasy.


1

How would you know what kind of inputs are acceptable? That is to say, if your client has no prior knowledge, how would you define the semantics of "surname"? You're starting to get into the territory of needing something like OWL. I think it's more practical to expect your clients to understand the semantics of well-known mime-types; say, for example, "...



Only top voted, non community-wiki answers of a minimum length are eligible