Thanks for the response Kyle. I'd like to get your opinion on the pros/cons of GData.
I'm working on a project that started as a tool for some buddies of mine that play in a band. They tour frequently and have numerous social network profiles. Basically, things were getting unmanageable for them in terms of keeping every web presence up to date. So I wrote an application that let them enter a tour date and then publish it to their social network profiles (using screen scraping + form filling). That tour date was also exposed via a web service and RSS feed which integrated with their official web site and also tied into their mailing list manager and would auto schedule email and text messages to be sent out based on a fans proximity to the venue. What was taking them hours to do, was now taking a few minutes. My grand vision is to create a set of REST web services that exposes music artist data - bios, discographies, tour dates, media (video/ music) etc. which would then be available for any social network, mashup or widget or other web enabled application to consume - we're already building a facebook application that will let facebook users browse shows/artist profiles. The upshot to the developer would be loads of great content and data to display and the upshot to the artist is that they can get much more exposure for no extra effort. For example, take a look at the following service (this is currently a SOAP service): http://www.gigpromoter.com/gpwebservices/bandservices.asmx/CurrentShows?bandcode=thethieves This is a rough cut - I need to apply the REST principles to the URI and also the content so that links to other resources (the artist, individual shows etc) are present - but you get the idea. I imagine developers being able to create mashups like this mockup: http://www.gigpromoter.com/mashup2.html - which combines google maps, youtube and my Artist API. The crossroads I am at is how to format the data in the request and response. APP is very interesting but seems very verbose and not very intuitive. For example, I use the old YouTube API to get the videos for the artists and the XML returned made a lot of sense and was very readable. The new YouTube API returns a much larger file and is less intuitive. So do I go with a more intuitive representation of the data or should I format it so that it supports APP and GData? Do the pros outway the cons? Your thoughts would be appreciated. Cheers Dan. On Sep 11, 7:01 am, Kyle <[EMAIL PROTECTED]> wrote: > On Sep 10, 8:03 pm, mysoniclife <[EMAIL PROTECTED]> wrote: > > > > > But how does this work with GData and APP? How are exceptions handled > > and is there a standard? Do I get back an ATOM feed with a single > > entry that contains the error code/message? > > > How does this work with the Google Calendar API if I try to post junk? > > Hi Dan, > > GData uses standard HTTP error (4xx) response codes to indicate > requests that could not be processed successfully and then includes > information about the error inside the HTTP response body. In your > specific example (a POST of a syntactically incorrect Calendar event), > this would be a 400 (Bad Request) response which the HTTP 1.1 spec > (rfc2616) defines as "The request could not be understood by the > server due to malformed syntax", which is pretty appropriate in this > circumstance. GData doesn't currently have a structured error > response body syntax as part of the protocol, but it has been > something that we've thought about as a future extension. > > I'm pretty sure most APP services will do something similar to the > above; the design center for APP (and lots of other REST models) is > to use existing HTTP conventions/mechanisms wherever possible. > > Cheers! > > -- Kyle --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Data API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-help-dataapi?hl=en -~----------~----~----~----~------~----~------~--~---
