RESTFest Wiki And Other News

10 views
Skip to first unread message

mca

unread,
Aug 23, 2014, 11:57:23 AM8/23/14
to rest...@googlegroups.com
Ok, RESTFEst is about a month away and things are in full swing.  Here's a quick update for everyone and some "things to do" for us all.

KEYNOTE
Sean Cribbs is our keynote on Friday -- it's gonna be awesome. You can check out his talk stuff here: http://www.restfest.org/speakers and follow Sean on twitter here: https://twitter.com/seancribbs

VENUE
We're having the event again this year at OpenWorks downtown (https://joinopenworks.com/). It's a great space and has lots of open areas where you can have "hallway talks" and just hang out.

WIKI TIME
ok, the Wiki has been posted and now we need to you help build it up.  Add your travel plans, any Food suggestions/restrictions, and -- most importantly -- your profile page. Since RESTFest is all about "Everybody Talks" that means everyone need to post at least one talk proposal on their profile page. You can check out my profile as a model to start (https://github.com/RESTFest/2014-Greenville/wiki/Mike-Amundsen) Yes, I know i don't have talks posted yet. Got me, eh?

FEATURED TALKS
Each year we have room for several "featured" or "extended" talks (30-60mins). If you want to propose a featured talk, mark that on your Wiki page. We select featured talks about a week or so before the event and will ping you when we build the schedule.

STACKDAY
Are you working with a cool library, framework, or tool? Did you create one? STACKDAY (friday AM) is a chance to show it off. Talks are usually 30 mins but can be shorter. Post your idea to the StackDay page and we'll schedule you in.

HACKDAY
In past years, we've had a theme for HackDay and usually had a single primary "leader" for the day. We're still open for ideas on this -- nothing is final. Last year Mogsie did a fantastic session where we built bots that worked together. In 2012 David Zuelke ran a great session on everyone using a single media type to build co-operative apps. Anyway, if you have an idea for hack day, post it to the HackDay page and let's see what transpires.

TRAVEL PAGES
Add your travel details to the wiki so we all know when you'll come in and where you are staying. If you can, share rides to/from the airport and from the hotel to the venue. That can cut dowen on gas, parking hassles, and add to the fun.

OK, that's a start. 
- create your profile
- add your talks
- add you travel details
- get packed for RESTFest.

Cheers

 

Chris White

unread,
Aug 23, 2014, 12:27:57 PM8/23/14
to rest...@googlegroups.com
Mike.

Permission to invite Grant Imahara to a Skype Q&A during REST Fest 2014?

You (or I) could moderate...we'd just need to give him a time to dial in.
--
You received this message because you are subscribed to the Google Groups "REST Fest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rest-fest+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Chris White
29609 \\ USA

mca

unread,
Aug 23, 2014, 12:33:21 PM8/23/14
to rest...@googlegroups.com

Totally yes!

We need to work out the sked. I think hackday is good (Thursday) but we could do Friday if that fits his sked better.

Let me know what you need from our end to get this locked in. As soon as its solid we can do an announcement.

BTW - congrats to the Trek Continues team for the Geekie!

Chris White

unread,
Aug 23, 2014, 1:00:05 PM8/23/14
to rest...@googlegroups.com
Just texted him a brief ask...will send an email next. Will let you know what I hear.

:-)

mca

unread,
Aug 23, 2014, 1:01:01 PM8/23/14
to rest...@googlegroups.com
very cool.

thanks for trying this out.

and looking forward to seeing you at RESTFest again this year.




Benjamin Young

unread,
Aug 25, 2014, 9:21:32 AM8/25/14
to rest...@googlegroups.com
For the Hack Day this year, I'd like to propose a good ole Hypermedia API "bake off."

The Bake Off would work in a similar fashion to bake off's or chili cook off's you may have been to before…but with less mess! ^_^

Folks would determine—either leading up to the event or Thursday morning—which Hypermedia API style / platform / system they'd like to use. There are loads of them now, and it'd be great to see as many as possible of them used to build a simple application—think todomvc.com but for hypermedia APIs.

What think ye? :)

If this sounds like a good path, I'd like to choose something simple (like todomvc) to scope things a bit, and then let folks start grouping up (or flying solo!) and researching / thinking ahead of the event.

Sound like a plan? :)

Later, friends,
Benjamin

mca

unread,
Aug 25, 2014, 9:31:03 AM8/25/14
to rest...@googlegroups.com
you mean scope out something like "todo" in general and then have folks build up hypermedia implementations of that?



Benjamin Young

unread,
Aug 25, 2014, 9:59:37 AM8/25/14
to rest...@googlegroups.com

Right. Something like defining what "chili" is before everyone tries to cook it. :)

Not the recipe for it. Just what it is.

Something like...
Please bring your best hypermedia to-do list API cooking skills to the rest fest hack day! Were looking for APIs that record:
- todo items
- due dates
- allow editing and deleting
- grouping into collections
- and whatever else you might want to through into the pot.

The goal being that at the end of the day we should all be sampling various types of "chili" vs. chilli, cake, coffee, cookies, and crumpets. :)

Make sense?

mca

unread,
Aug 25, 2014, 10:04:25 AM8/25/14
to rest...@googlegroups.com

I like it

mca

unread,
Aug 25, 2014, 1:23:23 PM8/25/14
to rest...@googlegroups.com
so, if we go forward w/ this we need a kind of "scope of work" document. something that focuses on the "things to get done" for the service. right?

does something like that already exist at the ToDoMVC sight?

or should we just work up something simple and post it in the repo?




Benjamin Young

unread,
Aug 25, 2014, 2:20:34 PM8/25/14
to rest...@googlegroups.com
Yeah, +1 for just using TodoMVC if their "Functionality" list is sufficient for a day of coding an API:

Are there any other constraints worth adding?
 - SHOULD use Hypermedia
 - MUST use stateless authentication (if implementing AUTH)
 - others?

Is RESTBucks from "REST in Practice" available outside of the book?

There's this implementation:

Ian (the author)'s repo is an implementation of it in Go:

But no spec…

Thoughts?

mca

unread,
Aug 25, 2014, 6:36:43 PM8/25/14
to rest...@googlegroups.com
yeah that set of specs is really UI-dependent. we need one that is a bit more generic, i think.

i like the ToDo idea since the "domain space" is relatively small and the oppty for creating cool apps is pretty big (shared todos, publishing them, creating dependent lists, searching, collating, etc.).

i think this is eaiser (and more fun) than the RESTBucks thing

anyone else want to weigh in here?




Darrel Miller

unread,
Aug 26, 2014, 7:24:03 AM8/26/14
to rest...@googlegroups.com
Definitely Todo over Restbucks. Never been a big fan of the Restbucks example.

Benjamin Young

unread,
Aug 26, 2014, 10:23:57 AM8/26/14
to rest...@googlegroups.com
k. Let's hash out what a basic Todo List API system should provide, but *without* dictating any URLs, etc. :)

Features
- CRUD of items
- grouping of items (collections, tags, categories, whatevah)
- assignment of item??
- auth??
- sharing??
- comments??
- ...??

Copy and paste that to the top, and modify as you see fit. :)

Once we've bounced it around a bit, we'll post it to the wiki and iterate it further (if needed).

Cool?

> -----Original Message-----
> From: rest...@googlegroups.com [mailto:rest...@googlegroups.com] On
> Behalf Of Darrel Miller
> Sent: Tuesday, August 26, 2014 7:24 AM
> To: rest...@googlegroups.com
> Subject: Re: [REST Fest] RESTFest Wiki And Other News
>

mca

unread,
Aug 26, 2014, 11:41:12 AM8/26/14
to rest...@googlegroups.com
Let's level-up a bit.

here's my shot at it:

ACTIONS
Users MUST be able to:
- create a new to-do item
- get a list of to-do items
- get a single to-do item
- mark a to-do item complete (or incomplete)

Users SHOULD be able to:
- edit a to-do item
- assign/change the due-date of a to-do item

Users MAY be able to:
- delete a to-do item

- get a list of category items
- get a single category item
- create a category item
- edit a category item
- assign/change the category of a to-do item
- delete a category item

- create a user account
- log in as an authenticated user
- edit the user account
- delete the user account

FIELDS
to-do items MUST have the following fields
- id (globally unique)
- title (name of the thing to do)

They SHOULD have:
- due-date 

They MAY have:
- notes (additional text about the item)
- category (this MAY hold more then one category value)
- useraccount (owner of the item)
- dateCreated
- dateUpdated

category items MUST have:
- id (globally unique)
- title (name of the category)

category items MAY have:
- dateCreated
- dateUpdated
- useraccount (user who created the item)

user items MUST have:
- id (globally unique)
- userName
- password

user items SHOULD have:
- givenName
- familyName

user items MAY have:
- avatarUrl
- dateCreated
- dateUpdated





Benjamin Young

unread,
Aug 26, 2014, 12:22:18 PM8/26/14
to rest...@googlegroups.com

I like all of it but the field name dictations. :) I suppose add long as fills know they can vary from those, then we'd be fine to offer / suggest them as a baseline for the data avalanche in each resource.

Should we rename category to "grouping" and add a note about multiple groupings being an option?

Should we define what we mean by "globally unique"--guessing that's app-wide unique vs. Planetary unique ATM? :)

Thanks, Mike!
Benjamin

mca

unread,
Aug 26, 2014, 12:25:18 PM8/26/14
to rest...@googlegroups.com
i think we need names for the fields so that independent client and server apps can communicate (think bots, etc.)

i'm totally ok w/ "word-smithing" the names, too. i suspect schema.org, IANA, microformats, Dublin Core all have existing names & definitions we can use.

of course, there are the *interface names*, not the UI labels or the storage field names. folks are free to do whatever they like there, right?





Benjamin Young

unread,
Aug 26, 2014, 1:13:02 PM8/26/14
to rest...@googlegroups.com
Isn't that what content negotiation is for? ^_^

But yeah, I'm cool with starting out with a baseline set of names for folks to use, and then see what other representations folks decide to offer.

Likely the "Stack Day" presentations will highlight this and other tangles of full-on hypermedia API "browsing." Should be good times! :D

Mind if I wiki what you wrote and promote it?

mca

unread,
Aug 26, 2014, 1:30:51 PM8/26/14
to rest...@googlegroups.com
yeah - put up an md doc and let's invite ppl to tweak it in the run up to the event.

we should proly also write up a description for the bake off. do you want to take a first stab at that?





Joel Clermont

unread,
Aug 26, 2014, 2:02:57 PM8/26/14
to rest...@googlegroups.com
I just wanted to chime in and say that I’ve been following along with the discussion and I like the direction it’s heading. At first, I thought it seemed a little too basic or too vague, but I like how this is taking shape. Thanks for working on this.

Joel Clermont

mca

unread,
Aug 26, 2014, 2:04:43 PM8/26/14
to rest...@googlegroups.com
joel:

feel free to dive into the doc once we get one posted. the more details we can work out ahead of tim ethe more fun we'll have at the bake-off.



Erik Mogensen

unread,
Aug 26, 2014, 7:59:25 PM8/26/14
to rest...@googlegroups.com
Not to pour cold water on this to-do list, but I have to ask the question: Is a to-do list in the realm of distributed hypermedia?  Or, let me rephrase this: Will we be building island APIs with silos of data?  Or will we be aiming for a distributed to-do list?

What is a distributed to-do list? What could it be?

Discuss. :-D
-- 
-mogsie-

mca

unread,
Aug 26, 2014, 8:01:39 PM8/26/14
to rest...@googlegroups.com

Supporting assignment could add more of what you are looking for, right?

Maybe adding a send operation to someone else and that someone need nor be on the same server?

--

Benjamin Young

unread,
Aug 26, 2014, 9:54:31 PM8/26/14
to rest...@googlegroups.com

+1 for making this actually leverage hypermedia a go beyond a single domain name.

 

Maybe that should be a requirement? :)

 

Good thoughts, mogsie!

 

From: rest...@googlegroups.com [mailto:rest...@googlegroups.com] On Behalf Of mca
Sent: Tuesday, August 26, 2014 8:02 PM
To: rest...@googlegroups.com
Subject: Re: [REST Fest] RESTFest Wiki And Other News

 

Supporting assignment could add more of what you are looking for, right?

mca

unread,
Aug 27, 2014, 10:28:24 AM8/27/14
to rest...@googlegroups.com
i just added two items to the spec to cover "sending a to-do item to a remote user"

UserAccount Field includes "userUrl" -- the URL address used when sending a to-item to a user"
and
Users MAY be able to "send a to-do item to a remote user (using the userUrl)"

look ok?




Benjamin Young

unread,
Aug 27, 2014, 10:30:20 AM8/27/14
to rest...@googlegroups.com
Looking good! :) I'm excited to see what variations we'll have on all of this by the time the day's out. :)

mca

unread,
Aug 27, 2014, 10:36:08 AM8/27/14
to rest...@googlegroups.com
we should proly select one or more media types to support for this project. Here's a sample.

"Servers SHOULD support one or more of the following media types"
- HAL
- Collection-JSON

"Servers MAY support any other media types they wish"
"Servers MAY allow clients to negotiate for a media type using the HTTP.ACCEPT header"

and we can proly just say everyone MUST use HTTP and MAY use additional protocols if they wish (WebSockets, XMPP, etc.)




Benjamin Young

unread,
Aug 27, 2014, 10:39:38 AM8/27/14
to rest...@googlegroups.com
Yeah, I'd be –1 on making anyone select media types at this point.

I have no delusions of these all working together. :) I mostly would like to see how each one "tastes" individually.

In my head it looks like a team of 2-5 people doing a demo at the end of some mix of server, client, and / or documentation (as much as they can get done) and showing how their API was built, the things they feel it offers, etc.

Maybe providing a list of available hypermedia API styles and media types would get things started in the right direction.

mca

unread,
Aug 27, 2014, 10:41:34 AM8/27/14
to rest...@googlegroups.com
ok, i'm fine w./ that. leave interop out of the spec for now. ppl can work that out in real time.

cool?



Benjamin Young

unread,
Aug 27, 2014, 1:35:33 PM8/27/14
to rest...@googlegroups.com
Yep. Perfect. I'll update the wiki on that wise.

/me is excited ^_^

mca

unread,
Aug 27, 2014, 1:40:45 PM8/27/14
to rest...@googlegroups.com
we proly need a bit of FAQ and schedule for the day to help ppl plan.

rought sample:

8:00 reg, coffee and pastries
9:00 welcome and opening remarks
9:15 QnA on the spec and working plan
9:30 team-up and project bids
10:00 start working
12:00 lunch break, review and food (pizza and drinks?)
13:00 continue greatness
16:00 meet up for demos
17:00 dinner break (brought in? on your own?)
18:00 continue for teams that want to keep working
21:00 closing up the building





Reply all
Reply to author
Forward
0 new messages