Sapere Aude
Tag: api
Designing in side-effects to GET requests is a fundamental mistake of web development that people who don’t understand the web/http tend to make. It’s less common now than it used to be, but I’m suprised to see it in a web API from one the biggest web properties and doubly surprised to see it called “REST”.
what is it with amazons infatuation with SOAP? how can they be a web company yet develop such lousy “API”s?
Today we’re launching the Google Chart API, a really simple tool for creating charts and graphs that are perfect for websites.
Let’s get straight in with an example. This URL:
http://chart.apis.google.com/chart?cht=p3&chd=s:hW&chs=250x100&chl=Hello|WorldCreates this image:
That’s it – no state, no calls, just send your data in an http request and get a png image graph back.
neat
nyt on their use of google maps and google calendar. if they continue like this maybe they won’t go extinct as predicted in epic 2014 🙂
nyt wonders if they should do an opensearch endpoint.
the first fully-functional message board that exists entirely within Google Earth. Talk about any location, store, restaurant, event or cool quirk in Google Earth.
In a notable but understated move, Google announced yesterday the availability of the GData JavaScript Client Library for Calendar. While on the surface this may seem like just another wrapper for the Google Calendar API like the ones provided for PHP and Java it’s actually a lot more interesting. Why? Because it’s one of the first examples of the next generation client-side APIs: one that doesn’t just let you fetch data, it lets you write data as well.
first js api that allows writes, too. at least for gdata
Yahoo! offered the fastest performance, the smallest total download, and the smallest memory footprint in my tests. Microsoft’s maps took a half-second longer to download and display than either of its competitors. Google had the highest total file count due to its mapping tile behavior.
we just did some optimizations, so that won’t be true for long.
if Yelp is really as good as it thinks it is, it wouldn’t need to put limits on the competition. After all, Google’s Maps API, the Flickr API and 10s of other similar APIs contain no such restrictions.
such insecurity
would it be possible to have CSV as an input format for the list of feed subscriptions in Venus? That way you could use Google Spreadsheets to collaboratively manage the list of feeds
using google spreadsheets. this is so much cooler than VBA
I should probably start out by pointing out that the title of this post is a lie. By definition, RESTful protocols can not be truly SQL-like because they depend on Uniform Resource Identifiers (URIs aka URLs) for identifying resources. URIs on the Web are really just URLs and URLs are really just hierarchical paths to a particular resource similar to the paths on your local file system (e.g. /users/mark/bobapples, A:\Temp\car.jpeg). Fundamentally URIs identify a single resource or aset of resources. On the other hand, SQL is primarily about dealing with relational data which meansyou write queries that span multiple tables (i.e. resources). A syntax for addressing single resources (i.e. URLs/URIs) is fundamentally incompatible with a query language that operates over multiple resources. This was one ofthe primary reasons the W3C created XQuery even though we already had XPath.
someone is trying to sell a thick client model here. NEED TO MAINTAIN CLIENT REVENUES
Gregor J. Rothfuss 