9. So what?
• Links convey options to the client
• Following Links captures the user’s intent
• Client is limited to dealing with the what, not the how
10. Hypermedia API – Example 2
Expense App
Home
Expenses
Approve
Unapprove
Receipt
{ExpenseId}
12. Conclusions
• Client state as an implementation artifact can be valuable
• Using Link types to encapsulate behavior isolates coupling and
enables re-use
• Allowing the server to take responsibility of application
workflow reduces dependencies on client UI frameworks
• Putting your business logic on the server can save you trips to
the app store
14. Image Credits
• Child https://www.flickr.com/photos/piulet/
• Tug of War https://flic.kr/p/nD2nj
• Web https://flic.kr/p/5RgD34
Editor's Notes
Developer advocate for Runscope.
Building line of business applications for 20 years.
Learning how to build hypermedia applications for the last 8 years.
Using rich client applications talking to hypermedia APIs.
When building distributed apps, developers can’t decide where to put the code.
Mainframes, PCs, Web, Javascript
I fear with our journey into the world of Javascript heavy clients we are going to make the same mistakes we made in the 90’s.
I found that REST/Hypermedia creates a nice balance of who does what. The code executes in the optimal place.
What is hypermedia? Hypermedia as the engine of application state
I could talk for hours on all the wonderful things that you can do with hypermedia. I’ve done lots of that.
We are starting to see examples of hypermedia in public APIs.
But I have seen very few examples of how to take advantage of it. Hypermedia APIs without clients that take advantage are a complete waste of time.
Epic, isn’t it.
But wait, it’s not read-only and it’s not CRUD.
For those who wish to debate the RESTfulness of this design, the door is over there. I jest, I am happy to discuss that at any time, just not in this talk . More code, less theory.