coolest API story?

[landlessness]

It's Friday (in some places)! I'm feeling all kinds of API love lately.

I keep running into startups, big corps, hobbyists, grandparents...who are doing awesome things with APIs.

anyone got a cool story or two about an API related thing that brought a tiny, little tear of joy to the eye?

-b

[Dave Goldberg]

Hi Brian,

I figure I might as well jump in here with my story (which is still
developing). Basically, I'm working with my 63-year-old dad on
developing a business rules API for apps and workflows that leverage
cloud services. We're still in fairly early stages of development, but
we think it could have some very cool applications (partly I'm
building it to scratch my own itch).

We've been talking about doing it for years, but never really dove in
until a few months ago. The sad part of the story is that the catalyst
for all of this was my mom passing away after a 6 month battle with
cancer. Tough times for our family, but my father and I have
strengthened our already strong relationship through this project.

We're both wide eyed dreamers, and the possibilities you get with a
robust API ecosystem (especially with hypermedia and self-describing
APIs) are amazing. We both get very excited thinking about these
things, as I'm sure many on this list do.

In any case, I think it's pretty special and unique that I am getting
to work with my dad in this way, even if nothing comes of it.

- Dave

[Wil Moore]

In any case, I think it's pretty special and unique that I am getting to work with my dad in this way, even if nothing comes of it.

Dave, that is awesome. I hope it goes well. Best of luck.

[Sam Ramji]

Wow. That is inspiring.

I hope you'll let the community here know what we can do to help!

Cheers,

Sam

[Kern Patton]

Dave, 

Great story, very inspiring. My father passed away several years back and I know what you are going through. 

If you need any help, give me a shout. 

Kern

[Larry Lv]

Dave,

That's really a *great* story, and thanks for sharing.

Something will come of it. Best of luck.


--
Sincerely,

Larry (@LarryLv)

[Dave Goldberg]

Thanks everyone. I really appreciate the thoughts and I am constantly
amazed at how communities like this develop (which is why I chose to
post here...I'm not a big poster). I look forward to updating you all
as we progress.

On May 15, 1:24 pm, Larry Lv <larrylv1...@gmail.com> wrote:
> Dave,
>
> That's really a *great* story, and thanks for sharing.
>
> Something will come of it. Best of luck.
>
> --
> Sincerely,
>

> *Larry (@LarryLv)
> *

[David Biesack]

OK, not quite as moving as Dave Goldberg's story, but this one also brought a (little) tear of joy to my eye. Here is a story I initially wrote for our internal blogs at SAS, to help show folks the benefit of REST-like web APIs. 

In my previous life at SAS, I administered a Jenkins/Maven CI environment for a small team. We came upon a nasty Maven bug. Maven is supposed to kill a forked JUnit process when it exceeds the allotted time, but Maven was was failing to kill the process. We were getting periodic unit tests failures (and therefore build failures) because these orphaned JUnit tests could lock resources, causing other unit tests to fail.

Let me describe how we worked around this problem using public APIs.

by hand

I created a solution in parts. First, I did things manually. I logged onto our CI build server and ran a ps(1) job,

  ps --no-headers -flu $buildUser --columns 512 | grep -v grep | grep 'surefire/surefirebooter'

searching for running surefire processes, while at the same time checking the Jenkins console to see if it was idle. If I found such processes still running when no builds were running, I killed 'em.

by machine

Well, I could not always be available to do this, so of course I automated this. First, I write a script to scan the ps output and kill any running surefire jobs (~/bin/kill-surefire); it used ~/bin/surefire-processes which is basically the ps command above.

Next, I wrapped this in a job ~/bin/monitor-processes that we added to our crontab for the $buildUser user.

by api

But how to verify that no Jenkins builds were active? I don't want to kill a legit JUnit test that has not timed out. This is where public APIs provide the solution I needed. Jenkins is nice (unlike Flash applications...) in that all of its screens and panels are accessible via distinct URLs. For example:

the main console is at http://buildsrv.example.com:8181/

the build servers attached to the instance are at http://buildsrv.example.com:8181/computer (we only use one build server)

Further, the content of every page is also accessible from an /api subpage, and you can request the content be delivered in XML or JSON. So, to check which jobs are running, we do the following:

curl --silent http://buildhost.domain:port/quietDown 

This quiesces the server, so it will not start any new builds. Currently running builds, if any, may continue.

curl --silent http://buildhost.domain:port/computer/api/xml 

and look for <idle>true</idle> in the output. (Technically, I should parse the XML, perhaps with xsltproc, instead of just using fgrep, but fgrep works just fine here.)

If there are no running builds in Jenkins, run ~/bin/kill-surefire

curl --silent http://buildhost.domain:port/cancelQuietDown 

to resume the server

by http

There is no custom Java or Ruby or Python binding necessary to talk to the Jenkins server; no custom socket or networking code or proprietary protocols are needed. It is controlled entirely through the HTTP server that is already running and serving normal web traffic. My script could have been written in Java or Scala or Perl or any number of other scripting languages. Importantly, the Jenkins developers did not have to create custom Java, C#, C, Ruby, Python or other binding for controlling the server. By using REST, they open the system to any client and don't alienate any developer community.

What I like is the uniformity: if you find information on a web page in Jenkins, it is trivial to find the API to fetch that information: just append /api/xml or /api/json to the URL. The cost of entry is exceedingly low.

buy it, yet?

As we evolve our own development, build, test, and production pipelines, we could leverage such API's internally to great advantage. No screen scraping to determine what builds passed or failed or when builds are scheduled to run; no screen scraping to find what third party jars are available for each track and what their versions are, or what is scheduled in what ship events.

All the metadata about the builds, pipeline, etc. could be exposed via RESTful APIs and tools and apps could consume them in myriad ways.

Ah, bliss.