This is really nice: Restfulie – Rest from Scratch. It’s a package of code for creating REST clients and servers with built in content type negotiation and other goodies. Watch the fun tour-do-force video too:
I’ve just finished writing part 3 of my series about DataRSS. Part 1 gives the background and justification for the concept, and Part 2 worked through a semi-believable scenario where having DataRSS would be a good thing.
In part 3 I try to get into more technical detail. I hope that you take the time to read it because that’s the only way I will get technical feedback on it. The reason I wrote the first two parts is that realistically I expect to lose 99.5% of you guys once you open up part 3. That’s why this post is labeled [GEEKY]. Here’s some of what I cover in part 3:
“Data RSS is a simple protocol and a simple data format. It can be implemented in any programming language.
Importantly, the Publisher and Accessor software need not know (can not know) what language the counterparties software is written in. ” (from DataRSS: Technical Overview)
“DataRSS is used between two parties, the Publisher, who ‘owns’ some data, and the Accessor, who wants to use that data. Publisher and Accessor are organizations with people in them. The Publisher wants to offer a technical means to allow an application program simple and standardized access to their data.
The Accessor wants to write an application program that accesses and does something useful with data coming from any Publisher. Accessor and Publisher don’t know each other. ” (from DataRSS: Technical Overview)
Delicious isn’t it? One final tease, I also have worked out some detailed examples of how DataRSS might work with the New York Times API, with the Sunlight Foundation API and with the Follow The Money API.
I want to start posting some of the cool things I am figuring out but so far I haven’t because I can’t really figure out how to organize it.
One area that I have immersed myself into is the many diverse groups who are doing work promoting government openness and transparency by, among many other things, creating the technical bridges to allow information that is already being collected to be more easily accessible. There are many of them, and one of them is the Sunlight Foundation. They are doing some really cool work, both themselves, and sponsoring and granting others who share their goals.
Wow what a long wind-up.
Anyway, in digging deeply into their APIs and datasets I decided to learn by doing and created a Ruby Gem called govsdk with the following goals:
- A simple and consistent sdk to all the various government (federal, state and local) APIs available.
- Totally hide from the user of the SDK what those APIs are, what the networking and REST pieces are. Instead provide classes which represent the natural domain objects and behind the scenes accesses appropriate datasets and APIs.
- Identify the ‘current’ best APIs for the various facts and figures so that the user need not do the work to learn each of the organizations and data models. When new ones come online or change, hide that as well.
- Provide all this in an open source library, for free, with example code, documentation and test suites.
Version 0.0.1 of the GovSdk GEM (0.0.1 — get the idea?) is implemented and available at GovSdk. Check it out, but expect it to change because this is still quite embryonic.