Adrian Cole
unread,Sep 25, 2012, 1:44:33 PM9/25/12Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to api-...@googlegroups.com
Hi, guys.
I'm presenting a talk on apis at JavaOne. Having lurked here a bit
now, I'm aware that folks that will attend this session aren't likely
already on the list. My guess is that some folks at the session come
in with an idea that rest==anything not soap. My goal isn't to
name/shame apis. Intention is to use real examples that show impact
(positive, negative in a context) of api design, and where possible
highlight rest ideas that correspond to them.
If you have some time, please inline your opinions, links to past
discussions, or whatever. I'll make the deck available next week, and
reference this api-craft thread as a source.
Super thanks for Mike and Tef for getting back to me on irc.
Abstract below.
Cheers,
-adrian
Title
I Got 99 Problems, but REST Ain’t One
Abstract
The world’s most popular services expose ReST APIs. Whether it’s in
Google, Twitter, Amazon,
or even your middleware, ReST is everywhere. Have you ever wondered
why APIs look the way
they do? Is there a balance between API design for usability and
scale, or can we have them both?
What’s the relationship between standards such as WS-* and ReST? This
session walks you
through the relationship between the ReST API and architecture. It
dissects popular APIs from
companies such as Amazon and Twitter and uncovers designs that
facilitate scale. Along the way,
the presentation identifies aspects that can be cherry-picked, versus
those that work best
together. It also underscores trade-offs you should know about when
putting together your API.