Ruby Midwest
BADCamp Notes
Drupal’s RESTful Future
TL;DR: services and feeds rock! We need to change the way we look at the server - web-servers are really build-servers.
Intro
Lately at AllPlayers.com I have been spending a lot of time working on API’s for our site and spending some time making Drupal talk web. Luckily, this is something that is being thought about a lot in the community (see: WSCCI, services.module); but, there are some interesting growing pains:
Drupal Camp Austin Re-cap
Drupal Camp Austin (DCA) was excellent - there was a great showing of drupalist and no shortage of excitement and learning. There were several great presentations ranging from security (config, code), business value, community reflection, advanced dev, and even an intro to features by me! Overall - the things that were talked about in the birds of a feather (BoF), in the halls, and when socializing can’t be traded for anything!
Here are some quick-hit notes:
- David Strauss
- libcloud
- Pressflow with events – think: node.js in drupal
- Ben Finklea
- Books
- No Mans Land
- E-myth
- Who
- Note: Kpi = key performance indicator (process)
- Books
- Greg Knaddison, Ben Jeavons
- add coder and security_review to Hudson tasks
- vuln
Web Services - Love Em’ and What a Cluster!
So, a little late night googling and it turns out that there is somewhat of a schism in the web services world. Now, without too much history I am kindof a services nut! However, I do not know how I missed this fight on the WSDL, REST, WADL acronym soup debate. As it turns out often enterprise-y tools do an amazing job at creating compatible (and even usable) web services endpoints, often in the form of SOAP with WSDL's describing the endpoint. A little investigation here reveals though just how hard it is to integrate a REST-ful endpoint to these service (often the value add of the extensible schema and type definitions quickly negates the simplicity of the REST). IMO this really leaves people in two camps - those with the automated *tools* to read the service endpoints (and quickly gain traction on interacting with the objects) and the simplicity of the REST interfaces that have very little overhead since they exploit the existing underlying architecture. I am not going to go into a tizzy here on why this seems really stupid (note to self - I should really write up some thoughts on this…)… because through this research I have stumbled onto a nifty google project: REST API code-gen (in all its computer science-y acronym laden goodness) - this is really cool (short description here)!!
Bam - Magic!

Woohoo - bringing robots to simple web services interfaces - I feel the future coming (unless its already dead)!
I Walked Into the Office the Other Day to This

sent via mobile