Thursday (September 17th)
REST Fest Hack Day is a bit different in the world of Hack-a-thons. The Hack Day (like the rest of REST Fest) is highly collaborative with attendees working together from different ends of the Web stack and problem space to accomplish a shared goal and leave collectively smarter because of their combined effort.
Often, we start with a centralizing idea, spec, theme, or goal. Then we build clients, servers, middle-ware and attempt to get them all working together toward the end of the day.
Add your idea below--feel free to make more pages, if you need. Also, tell the mailing list, so we can discuss it in more depth.
Write up your idea. Put your name by it. We'll vote the week before REST Fest on the rest-fest Google Group.
--- your idea goes here ---
Write up the brilliant in this space. You can link directly to your idea since it has it's very own header.
We'll have a server on-hand that provides a simple API and outputs responses in multiple hypermedia formats (HAL, Cj, Siren, UBER, etc.). Teams get together and create a generic hypermedia client that can handle at least one of the formats. Near the end of the day, new features/functionality will be added to the service -- well-implemented hypermedia clients will get the new features automatically w/o any code changes. Everyone goes home a winner! (mamund)
added by Doug Cone
Define an hypermedia API with Swagger and use to with render documentation, generate server, ...
(added by Arnaud Lauret)
We’ve filmed REST Fest talks since nearly the beginning—professionally for the last 3 years. Because of that, we’ve got quite a collection. It currently lives at http://videos.restfest.org/ which is just a Vimeo channel page for the previous year. Finding content is a fiddly, error prone process of searching all of Vimeo and usually coming up short.
What better way to fix it than to have ~50 people spend a full day creating a set of microservices, APIs, and clients to work together to build a new videos.restfest.org—complete with hypermedia hot sauce. - by BigBlueHat
Let's combine our experience and assemble some chapters on "API pitfalls" and/or "API Lessons" that we can share with the community. They may be technical or product-related in nature. Contribute an existing article as your chapter, write a new chapter, or team up with someone if you prefer. We can use plain text or markdown to publish to LeanPub, generate an eBook, and share it for free. If interested, we can solidify the book's theme, title, and outline w/ assignments. by James Higginbotham
BigBlueHat - I really like where this is headed! What do you think about doing this as an "always on" project related to our Video's Project? Regardless of the Hack Day, I can setup a repo for us all to start doing just what you describe, then we could try and publish the LeanPub book before the end of the year or at the time the next REST Fest is announced. Great thinking, James!
James Higginbotham - I love the idea, Ben - I'm totally up for what you described. It looks like I won't be in until later in the evening Thurs anyway, so if you have something setup then anyone can contribute what they like and I'll be happy to be an editor to pull it all together. We can then see what other topics come up from the Video's Project and discussions over REST Fest and see what else we can pull together by EOY or early next year.
James Higginbotham - I just realized what the name of the book should be: "REST Best 2015"
Open Source Project - Hypermedia Level-up
Pick an open source project(s) that is super useful, up and coming, or just plain likable. Fork it and make it Hypermedia awesome. Create pull requests if successful. Let's help some people out. Win 'em over with some value. by Ryan MacAwesome
- BigBlueHat recommends looking at comics.org and openlibrary.org. Both are (iirc) Django based. They have minimal (if any) API. They could both greatly benefit from a Hypermedia API and/or richer HTML. Great idea, Mr. MacAwesome.
It's hard to beat Ryan MacAwesome's proposal, but I'll try. A couple of years ago we had a hack day based on workflow systems, where the host brought a server which exposed a few media types and "passed out work" to the clients that were built in all sorts of languages. Back then, common feedback was that people wanted to write their own servers, or even they wanted to describe new workflows to the server so that it could orchestrate things in new ways.
My proposal is to allow just that by allowing for "decision making" hypermedia clients that can tell the server what course of action to do next, based on the history of the thing in question, provided to the decision making client, along with hypermedia controls on what it decides to do.
For a full example, we could try to build a "hypermedia chess game" (it's done before) but where the clients know they're playing chess, but the server doesn't. We might get a repeat of the hypermedia client that didn't know it was playing chess to see some really poor chess games, but also interactive chess games where (in a browser) you hop between chess games at random, playing the "next" move, for black or white. By Erik Mogensen (Slides from "demo")
- I've never been disappointed by anything Mr. Mogensen has suggested/presented! I like chess, so I'm down with this one too! Ryan MacAwesome
Slightly different than the idea suggested by Arnaud Lauret; Swagger is emerging a popular service description language, but in its current form, is not hypermedia aware and is arguably WSDL from the WS-* past with a JSON face to it. One could imagine creating a new hypermedia type based on swagger though that could change that. We could take leverage existing swagger descriptions and combine it with a new hypermedia type.
But why create a new media type one might ask? when there are already well thought out hypermedia types out there like uber, hydra etc. Why not build upon existing standards. Why not build extensions on top of HAL? HAL is fairly mature and great for describing resources and relationships. What if it also had support for describing actions?.
The idea is to augment/extend HAL using a given service description in the swagger dialect. Things that we can do:
- Brainstorm ideas on how to implement this, this is something that I suggested a while back, but I haven't had much bandwidth to pursue it. I also have some notes from chatting with Mike Amundsen a while back.
- How does one formulate a spec? Get to learn from people who've been there an done that! create a application/swagger+hal+json media type.
- Take an service (may be the microblogging example from Restfest of the past). Start with a swagger description of that service. and describe an actions using HAL. For e.g.
blog post (/posts/1) - links self - (/posts/1 GET) edit - (/posts/1 PUT) // --- describe this using HAL extensions
- Write a client to consume the newly minted media type.
submitted by Dilip Krishnan
Trying to finish UBER Hypermedia server for Go Fish card game
- Github Page: https://github.com/apiacademy/cardgame-srvc-arbiter
- Alpha version of the server: http://academy.messages.io:5000/
submitted by: Irakli Nadareishvili
- Github Page: http://jsclient.uberhypermedia.org/
submitted by Irakli Nadareishvili
- BitBucket Page: https://bitbucket.org/restfestviz/restfest-dashboard
submitted by Viz Pittsburgh
Goal oriented hypermedia workflow
Enabling hypermedia clients to focus on the goal over the REL.