Do you have adblock enabled?
 
If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(IT World)   Open Government Initiative leads White House to release We the People API, and lots of data on broccoli   (itworld.com ) divider line
    More: Interesting, We the People, Open Government Initiative, API, White House, broccoli, wild horses, open government, peas  
•       •       •

957 clicks; posted to Geek » on 03 May 2013 at 9:27 AM (3 years ago)   |   Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



19 Comments     (+0 »)
 
View Voting Results: Smartest and Funniest
 
2013-05-03 09:59:15 AM  
25.media.tumblr.com
Data on Broccoli!?!?!
 
2013-05-03 09:59:36 AM  
I think people undervalue the importance of the huge amount of data that has been made available in recent years because they get too focused on high-profile (and admittedly important) things like national security data.
 
2013-05-03 10:02:33 AM  
FTA:

Back in February, the White House hosted a hackathon with a couple of dozen programmers to help put the new API through its paces. Out of that came a handful of projects, some of which you can peruse here for inspiration. They'll be hosting another hackathon on June 1 as part of the National Day of Civic Hacking.

I thought our antiquated data-security laws made all hacking illegal.  Isn't that why the authorities drove Schwartz to kill himself?  So is June 1 just a honeypot?  Or is it only illegal when the government says so?

This isn't an intentional trolling, it's snark.
 
2013-05-03 10:15:53 AM  
Sigh. Their API guidelines made their way around as an example of something that is "probably better than what you can come up with" - but they're actually quite disappointing.

- Don't use the URI to denote content type. There's a freakin' header for that!
- Don't version your API using the URI (use content type parameters e.g. application/json; version=1.0 or better yet, just use hypermedia relationships to facilitate extensibility. That will cover most of your cases. If you're going to introduce something that breaks compatibility, you likely can't maintain the infrastructure (e.g. database) anyway! So having v1 accessible via a separate URI really won't help anyone. Most changes should be non-breaking, and the breaking ones are going to be a biatch to roll out anyway.

They didn't even try for REST, which I am proud of. It's nice to see that at least as far as I can tell, they didn't claim to be REST anywhere. That having been said... why the hell are query params used to fetch mock data? Just create mock.api.foo.com.
 
2013-05-03 10:19:02 AM  
I'd like to see the data on what data others want.
 
2013-05-03 10:39:59 AM  
The new API currently allows read-only access to data on petitions with at least 150 signatures. It allows you to query petitions based on date created, title/body text, signature count and status. You can also query signatures for a given petition and filter the results based on signee location and date

I unno, when you say "open government", I'm kind of looking for more information on what the government is doing, not what citizens on the Internet are doing.
 
2013-05-03 10:44:42 AM  

daveinsurgent: Sigh. Their API guidelines made their way around as an example of something that is "probably better than what you can come up with" - but they're actually quite disappointing.


API Nazis are my favorite kind of Nazis.  Is it documented?  Does it get me the info I'm looking for?  Ok then, it's a good API.

/ HTTP headers are nice in theory and all, but there's a lot of practical situations you often need to support (i.e. JSONP) where you just can't use them reliably.  I put everything in the query string.
 
2013-05-03 10:56:58 AM  

serial_crusher: daveinsurgent: Sigh. Their API guidelines made their way around as an example of something that is "probably better than what you can come up with" - but they're actually quite disappointing.

API Nazis are my favorite kind of Nazis.  Is it documented?  Does it get me the info I'm looking for?  Ok then, it's a good API.

/ HTTP headers are nice in theory and all, but there's a lot of practical situations you often need to support (i.e. JSONP) where you just can't use them reliably.  I put everything in the query string.


Right now, I would honestly kill to have my company understand that an API is useless without thorough documentation. These chuckleheads believe that their API, a mishmash of everything from PowerShell cmdlets and JavaScript classes to WCF services wrapped by custom proxy classes, is "practically self-documenting." (No, I'm not making that up.)

Thanks to that stupidity, and the short-sightedness which dictated that terminating all but two UA staff for a 500+ employee software company would save us a bundle this year, we're going to ship a massive amount of code to customers that won't be able to use it.
 
2013-05-03 11:00:43 AM  

serial_crusher: daveinsurgent: Sigh. Their API guidelines made their way around as an example of something that is "probably better than what you can come up with" - but they're actually quite disappointing.

API Nazis are my favorite kind of Nazis.  Is it documented?  Does it get me the info I'm looking for?  Ok then, it's a good API.

/ HTTP headers are nice in theory and all, but there's a lot of practical situations you often need to support (i.e. JSONP) where you just can't use them reliably.  I put everything in the query string.


Naive pragmatists are my favorite. Their "achievements" keep them mobile enough so that they're never around when their awful concessions (everything in the query string, awesome! I never cared about caching) cause problems. I'm far from a purist, but good design and engineering aren't hard things to incorporate. It's just that most people are so busy talking about how agile they are and how REST their APIs is that when it comes time to deliver they cowboy up and then use pragmatism as their defense mechanism against any indication they could have had foresight in what they were doing. Hey, we have daily stand-ups, what does it matter if nobody on the team an follow SOLID. As long as they can recite the acronym!

Go write more Ruby or PHP and remember, transactions were invented to slow you down. I don't know what the hell JSONP has to do with HTTP headers, in fact, using Content-Type specifically for JSONP makes perfect sense:

Accept: application/javascript; callback=parseResult
Accept: application/jsonp; padding=someCallback

whatever.
 
2013-05-03 11:06:38 AM  

daveinsurgent: serial_crusher: daveinsurgent: Sigh. Their API guidelines made their way around as an example of something that is "probably better than what you can come up with" - but they're actually quite disappointing.

API Nazis are my favorite kind of Nazis.  Is it documented?  Does it get me the info I'm looking for?  Ok then, it's a good API.

/ HTTP headers are nice in theory and all, but there's a lot of practical situations you often need to support (i.e. JSONP) where you just can't use them reliably.  I put everything in the query string.

Naive pragmatists are my favorite. Their "achievements" keep them mobile enough so that they're never around when their awful concessions (everything in the query string, awesome! I never cared about caching) cause problems. I'm far from a purist, but good design and engineering aren't hard things to incorporate. It's just that most people are so busy talking about how agile they are and how REST their APIs is that when it comes time to deliver they cowboy up and then use pragmatism as their defense mechanism against any indication they could have had foresight in what they were doing. Hey, we have daily stand-ups, what does it matter if nobody on the team an follow SOLID. As long as they can recite the acronym!

Go write more Ruby or PHP and remember, transactions were invented to slow you down. I don't know what the hell JSONP has to do with HTTP headers, in fact, using Content-Type specifically for JSONP makes perfect sense:

Accept: application/javascript; callback=parseResult
Accept: application/jsonp; padding=someCallback

whatever.


You must work for a company that gives you unlimited time to make things correctly...

/not that you're entirely wrong
 
2013-05-03 11:15:54 AM  
I'd argue there's a difference between perfect and correct. Correct certainly means "the best we could do with what we have" - but that's completely subjective, and I'm arguing that the drum of pragmatism gets beat often as an excuse for not thinking about things that might not be pleasant to think about. An example of this is the sheer number of MVC frameworks for web applications. MVC is not a web paradigm, but people don't want to deal with thinking about the complexities of an actual hypermedia driven system (as opposed to something that is just hypermedia aware, if said framework even lets you do that! Most of them think they're doing you a favor by attempting to abstract that away from you, despite the fact it's a huge leaky abstraction).

I read 10+ hours a week over and above the 40 I put in at work. I write stuff and throw it away immediately just to exercise. It's valuable necessary in making those kind of decisions. I'm not a fool, I don't make perfect designs, and I make lots of mistakes in doing so - but I don't accept status quo until the next buzzword shuffles things around and management demands we bolt it on to our product, either. I am mindful of being pragmatic in what I do, but I try my best not to allow it to become a short-circuit for when I encounter a problem that I don't want to have to deal with. Anyone who's ever worked with a database "designed" by someone who doesn't understand foreign keys can hopefully appreciate that.
 
2013-05-03 11:24:49 AM  

daveinsurgent: I don't know what the hell JSONP has to do with HTTP headers, in fact, using Content-Type specifically for JSONP makes perfect sense:


Have I been missing out on some way to tell browsers what HTTP headers to send on the underlying request behind a <script> tag?
Last time I worried about that particular problem I still had to support IE6, so maybe things have changed for those of you lucky enough to only support modern browsers (in which case, why would you even be using JSONP instead of one of CORS), but AFAIK you're still limited to just telling it what URL to fetch...
 
2013-05-03 11:34:04 AM  

serial_crusher: daveinsurgent: I don't know what the hell JSONP has to do with HTTP headers, in fact, using Content-Type specifically for JSONP makes perfect sense:

Have I been missing out on some way to tell browsers what HTTP headers to send on the underlying request behind a <script> tag?
Last time I worried about that particular problem I still had to support IE6, so maybe things have changed for those of you lucky enough to only support modern browsers (in which case, why would you even be using JSONP instead of one of CORS), but AFAIK you're still limited to just telling it what URL to fetch...


Here's a 3 year old stack overflow post incase you just don't know how JSONP works.  If it contains outdated information, you should go give it a correct answer.
/ Yes, as the second answer there indicates, you can use flyJSONP to proxy your requests through Yahoo's server, if you don't care about performance.
// Arrogance when you're wrong is the best kind of arrogance.
 
2013-05-03 11:39:37 AM  

daveinsurgent: I read 10+ hours a week over and above the 40 I put in at work.


Only 40 hours a week?  Now I _know_ you work for a company that gives you all the time in the world.
 
2013-05-03 11:41:37 AM  

serial_crusher: (in which case, why would you even be using JSONP instead of one of CORS)


Possibly because CORS support in IIS and ASP.NET kinda sucks?  (Or at least doesn't work the way I think it should...)

/Ended up having to allow all
//Wanted to only allow specific hosts...
 
2013-05-03 12:52:13 PM  

Telos: serial_crusher: (in which case, why would you even be using JSONP instead of one of CORS)

Possibly because CORS support in IIS and ASP.NET kinda sucks?  (Or at least doesn't work the way I think it should...)

/Ended up having to allow all
//Wanted to only allow specific hosts...


I haven't been able to get cross-domain PUT, POST or DELETE to work yet for this reason. I've managed to hack together a solution using GET and a JSONP filter attribute on an MVC controller. You just tell the page to "get" the url with "add", "edit", or "delete" tacked on as part of the data, do your data functions on the back end and return something on success. It is, as my old supervisor would call it, a kludgy hack, and dirty as hell but it works. It seems kludgy hacks are going to be the norm until a standard is adopted by more browsers/servers. Even Oracle Webcenter uses a method for doing this that for the most part is considered an avenue of attack rather than a legitimate way to allow RESTful traffic. Can't remember the acronym for the life of me.
 
2013-05-03 05:25:46 PM  
I was wrong in my argument about JSONP - admittedly because I've never used it. I never would, either, because good god - create a proxy resource. Concerns about performance are unfounded given that you're giving up caching by using query params.

That having been said - don't use query params. Use URI fragments then.

/foo/bar;jsonp=myCallback/

The point was about versioning using the URI.
 
2013-05-03 05:58:35 PM  

daveinsurgent: I was wrong in my argument about JSONP - admittedly because I've never used it. I never would, either, because good god - create a proxy resource. Concerns about performance are unfounded given that you're giving up caching by using query params.


Well, caching only breaks to the extent that things change in the query string.  So yeah, most people use jQuery's out of the box implementation that gives a random name to the callback function.  On all my stuff I use a sequentially generated ID based on the order in which things are called on the page, so stuff that happens in the same order every pageload (which is most of what Ideal with) can be cached at the CDN.  Stuff that happens out of sequence, yeah that's the same.

We've got a large number of cache misses as well.  Stuff that contains time sensitive, user-personalized data (and we don't really do as much as we should to split the cacheable pieces away from the non-cacheable pieces, but hey I can't just go redesigning everything myself).  So the proxying solution really does have a noticeable hit.  Our servers are physically nowhere near our customer's, so you have to make twice as many round trips across the Internet, which is Kind of a Big Deal.
Proxying would also require us to tell our customers to build and setup the proxy on their end, pay for the extra bandwidth going through their proxy.  Believe me, telling customers to do work is a way harder problem to solve than it should be.
 
2013-05-03 06:00:45 PM  

serial_crusher: Stuff that happens out of sequence, yeah that's the same


I should proofread before posting instead of after.  That was supposed to say "yeah, that won't always get cached" or something.
 
Displayed 19 of 19 comments

View Voting Results: Smartest and Funniest

This thread is archived, and closed to new comments.

Continue Farking
Submit a Link »
On Twitter








In Other Media
  1. Links are submitted by members of the Fark community.

  2. When community members submit a link, they also write a custom headline for the story.

  3. Other Farkers comment on the links. This is the number of comments. Click here to read them.

  4. Click here to submit a link.

Report