Building web services that play nicely with other web services

Upcoming has been very actively improving its web services API over the last week or two, and a few of their most recent changes have allowed us to integrate upcoming.org into 43things.com:

Events on city pages. You can now see upcoming events on any of our city pages. It’ll display the next 10 events in that city and link to upcoming.org for the rest.

Call our web services with Upcoming’s IDs. You can now get city information from our web services by passing Upcoming’s metro_id instead of our id. We’re hoping that this’ll make it easier to combine web services if, say, someone wanted to create a site that matched goals up with events and plotted them on a google map along with all of the craigslist apartments that were available for rent. At least, they wouldn’t have to do an extra search on our site to match the cities together. This kind of stuff makes my brain spin, but it’s the future!

More info added to person requests. While we were mucking about with the web services, we also added a couple extra fields to the Person object (the XML that gets returned whenever a person or a list of people is requested). First, we added the Upcoming.org metro_id for those people who’ve let us know which city they live in. Second, we added the flickr_username for anyone that’s associated their flickr photos with their 43 Things account. Here’s my profile as an example. Again, we’re hoping that by consolidating some of the various information about a person on the web, that people will be able to do cool things more easily.

Finally, all of the person-related method calls now support requests where you pass us someone’s flickr_username instead of their 43 Things username. It would be fairly easy for someone that’s already getting information from flickr to send out one extra call and get that person’s goals, or their entries, or their teammates, or their tags.

This is where we see web services getting really interesting. When the web services start playing nicely with one another, you can begin to string them all together and build things that are greater than the sum of their parts. Let us know if you build anything with any of this and we’ll link to it from here.

For full documentation of our web services, go here.

About these ads

5 responses to “Building web services that play nicely with other web services

  1. Good stuff fellas!<br />
    <br />
    It’s inspiring to see you guys and Andy @ Upcoming so on the ball lately.<br />
    <br />
    It’s definately encouraging.

  2. Oh, great, update the api while I’m on a vacation. ;^) <br />
    <br />
    I’ll get r43 updated next week when I get back.

  3. Since stuff happens at places, at times and with people, ideally there would be some sort of agreed on standards/keys that would sort these things out. I can’t wait to see things come together just a bit more.. so I can see an event on a map with the attendees (with their 43 things) so I can find someone who lives near me and isn’t a jerk to IM/call/email/SMS/etc for a ride.<br />
    <br />
    Kevin

  4. Maybe I’m a stupid one, I wrote then comment but forgot the submit it :S, well I’ll write it again.<br />
    <br />
    I think it would be very helpfully for al the developers out who are doing great things with the webservices to have all of then work in a common way, ie, having the chance of use info from different sources for the same person. I been thinking about it and though that a good point could be to have something like a “passport” (sorry :( ) for this kind of sites, that way we wouldn’t worry about different user for diffeerent places, I will have the pviojo username and will use it for flickr, 43 things, and a lot of sites I am currently signed.<br />
    One of the difficulties I can see about this is the use of the information, I suggest using a kind of “common” publicity policy, as was discussed in another post.<br />
    I think this is a great way for having all of our information, and from other users disponible in a common basis.<br />
    <br />
    Keep on working guys, this gonna be great.

  5. A simple way to deal with the need for a universal identitifier is to use email addresses for the login. Obvious problem being when you change your email / forget password etc.. and some people might not want their email public.. <br />
    <br />
    mygmaps.com looks awesome.. I hope it doesn’t break or that google makes their own API to do this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s