we've been talking internally about v2 of the api for a couple of weeks now
we're doing a high level pass of things that work well and things we'd like to see changed. we wanted to share a few of these sooner rather than later so as to get your feedback
- JSON-only: will be a great way to simplify everything: interface, testing, documentation, etc.
- OAuth-only: believe it or not, this is how the v1 api started -- and then we backed off because we saw so much demand for a basic http auth version. at the very least, how do you guys feel about a two-pass system (use our auth exchange system to handoff login for oauth tokens)? that is, all methods except the initial token exchange will be oauth-enforced. because of the token exchange (which v1 already supports [1]), your app will not have to do a complicated dance into and out of a web view if it doesn't want to (or has a technically difficult time doing so)
- ...?
you've all thrown out great ideas the last few months so i'm really curious what other things you're thinking about. please follow up in this thread with any and all comments!
On Fri, Apr 2, 2010 at 3:14 PM, naveen <naveen...@gmail.com> wrote: > we've been talking internally about v2 of the api for a couple of > weeks now
> we're doing a high level pass of things that work well and things we'd > like to see changed. we wanted to share a few of these sooner rather > than later so as to get your feedback
> - JSON-only: will be a great way to simplify everything: interface, > testing, documentation, etc.
> - OAuth-only: believe it or not, this is how the v1 api started -- and > then we backed off because we saw so much demand for a basic http auth > version. at the very least, how do you guys feel about a two-pass > system (use our auth exchange system to handoff login for oauth > tokens)? that is, all methods except the initial token exchange will > be oauth-enforced. because of the token exchange (which v1 already > supports [1]), your app will not have to do a complicated dance into > and out of a web view if it doesn't want to (or has a technically > difficult time doing so)
> - ...?
> you've all thrown out great ideas the last few months so i'm really > curious what other things you're thinking about. please follow up in > this thread with any and all comments!
> Twitter learned this and still gets an several emails a day to add XML to > their search API. :-)
> Zac Bowling
> On Fri, Apr 2, 2010 at 3:14 PM, naveen <naveen...@gmail.com> wrote: > > we've been talking internally about v2 of the api for a couple of > > weeks now
> > we're doing a high level pass of things that work well and things we'd > > like to see changed. we wanted to share a few of these sooner rather > > than later so as to get your feedback
> > - JSON-only: will be a great way to simplify everything: interface, > > testing, documentation, etc.
> > - OAuth-only: believe it or not, this is how the v1 api started -- and > > then we backed off because we saw so much demand for a basic http auth > > version. at the very least, how do you guys feel about a two-pass > > system (use our auth exchange system to handoff login for oauth > > tokens)? that is, all methods except the initial token exchange will > > be oauth-enforced. because of the token exchange (which v1 already > > supports [1]), your app will not have to do a complicated dance into > > and out of a web view if it doesn't want to (or has a technically > > difficult time doing so)
> > - ...?
> > you've all thrown out great ideas the last few months so i'm really > > curious what other things you're thinking about. please follow up in > > this thread with any and all comments!
> we've been talking internally about v2 of the api for a couple of > weeks now
> we're doing a high level pass of things that work well and things we'd > like to see changed. we wanted to share a few of these sooner rather > than later so as to get your feedback
> - JSON-only: will be a great way to simplify everything: interface, > testing, documentation, etc.
> - OAuth-only: believe it or not, this is how the v1 api started -- and > then we backed off because we saw so much demand for a basic http auth > version. at the very least, how do you guys feel about a two-pass > system (use our auth exchange system to handoff login for oauth > tokens)? that is, all methods except the initial token exchange will > be oauth-enforced. because of the token exchange (which v1 already > supports [1]), your app will not have to do a complicated dance into > and out of a web view if it doesn't want to (or has a technically > difficult time doing so)
> - ...?
> you've all thrown out great ideas the last few months so i'm really > curious what other things you're thinking about. please follow up in > this thread with any and all comments!
+1 for JSON-only being ok. Each API I've worked with has had some different form of JSON or XML and I survived. There are so many libraries available to parse the HTTP response that this is no longer an issue.
On Fri, Apr 2, 2010 at 3:28 PM, Geoff <fro...@gmail.com> wrote: > I'm fine with JSON only, but I know others probably won't want to move > away form XML.
> I wouldn't hate moving to OAuth, but it'll take a fair amount of > rewriting on my part, just because of how baked-in Basic Auth is right > now.
> On Apr 2, 5:14 pm, naveen <naveen...@gmail.com> wrote: >> we've been talking internally about v2 of the api for a couple of >> weeks now
>> we're doing a high level pass of things that work well and things we'd >> like to see changed. we wanted to share a few of these sooner rather >> than later so as to get your feedback
>> - JSON-only: will be a great way to simplify everything: interface, >> testing, documentation, etc.
>> - OAuth-only: believe it or not, this is how the v1 api started -- and >> then we backed off because we saw so much demand for a basic http auth >> version. at the very least, how do you guys feel about a two-pass >> system (use our auth exchange system to handoff login for oauth >> tokens)? that is, all methods except the initial token exchange will >> be oauth-enforced. because of the token exchange (which v1 already >> supports [1]), your app will not have to do a complicated dance into >> and out of a web view if it doesn't want to (or has a technically >> difficult time doing so)
>> - ...?
>> you've all thrown out great ideas the last few months so i'm really >> curious what other things you're thinking about. please follow up in >> this thread with any and all comments!
On Fri, Apr 2, 2010 at 15:14, naveen <naveen...@gmail.com> wrote: > we've been talking internally about v2 of the api for a couple of > weeks now
> we're doing a high level pass of things that work well and things we'd > like to see changed. we wanted to share a few of these sooner rather > than later so as to get your feedback
> - JSON-only: will be a great way to simplify everything: interface, > testing, documentation, etc.
> - OAuth-only: believe it or not, this is how the v1 api started -- and > then we backed off because we saw so much demand for a basic http auth > version. at the very least, how do you guys feel about a two-pass > system (use our auth exchange system to handoff login for oauth > tokens)? that is, all methods except the initial token exchange will > be oauth-enforced. because of the token exchange (which v1 already > supports [1]), your app will not have to do a complicated dance into > and out of a web view if it doesn't want to (or has a technically > difficult time doing so)
> - ...?
> you've all thrown out great ideas the last few months so i'm really > curious what other things you're thinking about. please follow up in > this thread with any and all comments!
> To unsubscribe, reply using "remove me" as the subject.
-- Abraham Williams | Community Advocate | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
JSON only means that I'd have to largely have rewrite my entire app (python based using xml.dom.minidom - which is fine if v2 brings some cool goodies... ) Since nobody is paying me to maintain barriosquare you could see that I'd rather be drinking than converting code to JSON instead of XML.
I'm cool with OAuth only as that's how my app works now...
Is there a trend for RESTful APIs to going to JSON instead of XML?
I just groan on having to convert the entire thing (it's selfish, I know..)
... will you support mix-match of API versions? So we can continue using the old xml versions but code in JSON for new API features?
On Fri, Apr 2, 2010 at 6:59 PM, Abraham Williams <4bra...@gmail.com> wrote: > +1 on both. The less you have to maintain the better it will be and the > sooner new awesome stuff gets rolled out.
> Abraham
> On Fri, Apr 2, 2010 at 15:14, naveen <naveen...@gmail.com> wrote:
>> we've been talking internally about v2 of the api for a couple of >> weeks now
>> we're doing a high level pass of things that work well and things we'd >> like to see changed. we wanted to share a few of these sooner rather >> than later so as to get your feedback
>> - JSON-only: will be a great way to simplify everything: interface, >> testing, documentation, etc.
>> - OAuth-only: believe it or not, this is how the v1 api started -- and >> then we backed off because we saw so much demand for a basic http auth >> version. at the very least, how do you guys feel about a two-pass >> system (use our auth exchange system to handoff login for oauth >> tokens)? that is, all methods except the initial token exchange will >> be oauth-enforced. because of the token exchange (which v1 already >> supports [1]), your app will not have to do a complicated dance into >> and out of a web view if it doesn't want to (or has a technically >> difficult time doing so)
>> - ...?
>> you've all thrown out great ideas the last few months so i'm really >> curious what other things you're thinking about. please follow up in >> this thread with any and all comments!
>> To unsubscribe, reply using "remove me" as the subject.
> -- > Abraham Williams | Community Advocate | http://abrah.am > PoseurTech Labs | Projects | http://labs.poseurtech.com > This email is: [ ] shareable [x] ask first [ ] private.
> -- > To post to this group, send email to foursquare-api@googlegroups.com
oh, nevermind about the dumbphone part. my understanding was a bit different than reality.
i guess i wouldn't mind; i learned a bunch of stuff in order to write my app with XML, so JSON won't kill me. if this means we get access to things like leaderboard & city changes i'm in. i hope both versions will be supported in parallel for a few weeks?
JSON wasn't reliable for v1 (malformations would cause parsers to crap out), so early on we had to switch to XML. You're forcing everyone who used XML and basic auth to rewrite everything. Any custom APIs that people developed will have to be completely rewritten. Personally, I think that if you're going to completely ditch half the API, we should have more notice. I don't know when you're planning to come out with v2, but wouldn't it be normal to deprecate those things for v2 and then ditch them completely in v3?
-S
On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote:
> oh, nevermind about the dumbphone part. my understanding was a bit > different than reality.
> i guess i wouldn't mind; i learned a bunch of stuff in order to write > my app with XML, so JSON won't kill me. if this means we get access > to things like leaderboard & city changes i'm in. i hope both > versions will be supported in parallel for a few weeks?
My vote is for progress. The Foursquare team's time would be wasted on supporting old stuff or options that would make only 20% of developers happy. Make cool new stuff and make 80% of developers happy instead. :) Every platform has API options for JSON and OAuth (aren't some even Foursquare-specific?) so it shouldn't be that hard for devs to incorporate.
Do JSON only and OAuth only for /v2. Continue to keep the lights on for /v1 for some amount of time, maybe a year. If apps pointing to /v1 can't upgraded in a year's time, then to be honest I wonder how interesting such a rarely upgraded app would be in the first place. To be nice, track which apps continue to hit /v1 stuff that's deprecated, and reach out to those devs outside of the mailing list.
Other thing I'd like to see, and this is just silly and doesn't have much to do with /v2, but it'd be super handy if the API doc page had an alphabetized list of links to anchors on the page. I always either get lost scrolling or fail to command + F through because I forget the exact method name.
> JSON wasn't reliable for v1 (malformations would cause parsers to crap > out), so early on we had to switch to XML. You're forcing everyone > who used XML and basic auth to rewrite everything. Any custom APIs > that people developed will have to be completely rewritten. > Personally, I think that if you're going to completely ditch half the > API, we should have more notice. I don't know when you're planning to > come out with v2, but wouldn't it be normal to deprecate those things > for v2 and then ditch them completely in v3?
> -S
> On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: >> oh, nevermind about the dumbphone part. my understanding was a bit >> different than reality.
>> i guess i wouldn't mind; i learned a bunch of stuff in order to write >> my app with XML, so JSON won't kill me. if this means we get access >> to things like leaderboard & city changes i'm in. i hope both >> versions will be supported in parallel for a few weeks?
> -- > To post to this group, send email to foursquare-api@googlegroups.com
As part of v2 I'd like to see push-type notification to allow other non-iphone apps and api consumers to get notified when friends checkin, etc. :-)
Sure, come up with a clear migration path to a v2 which supports JSON only, keep the lights on v1 for at least a year - don't alienate those developers who have invested the time since the beginning with foursquare.
On Fri, Apr 2, 2010 at 10:37 PM, Brian Papa <bp...@me.com> wrote: > My vote is for progress. The Foursquare team's time would be wasted on > supporting old stuff or options that would make only 20% of developers > happy. Make cool new stuff and make 80% of developers happy instead. :) > Every platform has API options for JSON and OAuth (aren't some even > Foursquare-specific?) so it shouldn't be that hard for devs to incorporate.
> Do JSON only and OAuth only for /v2. Continue to keep the lights on for /v1 > for some amount of time, maybe a year. If apps pointing to /v1 can't > upgraded in a year's time, then to be honest I wonder how interesting such a > rarely upgraded app would be in the first place. To be nice, track which > apps continue to hit /v1 stuff that's deprecated, and reach out to those > devs outside of the mailing list.
> Other thing I'd like to see, and this is just silly and doesn't have much > to do with /v2, but it'd be super handy if the API doc page had an > alphabetized list of links to anchors on the page. I always either get lost > scrolling or fail to command + F through because I forget the exact method > name.
> On Apr 2, 2010, at 8:15 PM, sabernar wrote:
> > -2
> > JSON wasn't reliable for v1 (malformations would cause parsers to crap > > out), so early on we had to switch to XML. You're forcing everyone > > who used XML and basic auth to rewrite everything. Any custom APIs > > that people developed will have to be completely rewritten. > > Personally, I think that if you're going to completely ditch half the > > API, we should have more notice. I don't know when you're planning to > > come out with v2, but wouldn't it be normal to deprecate those things > > for v2 and then ditch them completely in v3?
> > -S
> > On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: > >> oh, nevermind about the dumbphone part. my understanding was a bit > >> different than reality.
> >> i guess i wouldn't mind; i learned a bunch of stuff in order to write > >> my app with XML, so JSON won't kill me. if this means we get access > >> to things like leaderboard & city changes i'm in. i hope both > >> versions will be supported in parallel for a few weeks?
> > -- > > To post to this group, send email to foursquare-api@googlegroups.com
If your application requires a huge amount of work to switch from XML to JSON you are doing something wrong. You should be able to switch out your parser, modify you code to work with the new parser and be good to go.
Abraham
On Fri, Apr 2, 2010 at 19:51, Christopher Burris <ch...@chilitechno.com>wrote:
> As part of v2 I'd like to see push-type notification to allow other > non-iphone apps and api consumers to get notified when friends checkin, etc. > :-)
> Sure, come up with a clear migration path to a v2 which supports JSON only, > keep the lights on v1 for at least a year - don't alienate those developers > who have invested the time since the beginning with foursquare.
> On Fri, Apr 2, 2010 at 10:37 PM, Brian Papa <bp...@me.com> wrote:
>> My vote is for progress. The Foursquare team's time would be wasted on >> supporting old stuff or options that would make only 20% of developers >> happy. Make cool new stuff and make 80% of developers happy instead. :) >> Every platform has API options for JSON and OAuth (aren't some even >> Foursquare-specific?) so it shouldn't be that hard for devs to incorporate.
>> Do JSON only and OAuth only for /v2. Continue to keep the lights on for >> /v1 for some amount of time, maybe a year. If apps pointing to /v1 can't >> upgraded in a year's time, then to be honest I wonder how interesting such a >> rarely upgraded app would be in the first place. To be nice, track which >> apps continue to hit /v1 stuff that's deprecated, and reach out to those >> devs outside of the mailing list.
>> Other thing I'd like to see, and this is just silly and doesn't have much >> to do with /v2, but it'd be super handy if the API doc page had an >> alphabetized list of links to anchors on the page. I always either get lost >> scrolling or fail to command + F through because I forget the exact method >> name.
>> On Apr 2, 2010, at 8:15 PM, sabernar wrote:
>> > -2
>> > JSON wasn't reliable for v1 (malformations would cause parsers to crap >> > out), so early on we had to switch to XML. You're forcing everyone >> > who used XML and basic auth to rewrite everything. Any custom APIs >> > that people developed will have to be completely rewritten. >> > Personally, I think that if you're going to completely ditch half the >> > API, we should have more notice. I don't know when you're planning to >> > come out with v2, but wouldn't it be normal to deprecate those things >> > for v2 and then ditch them completely in v3?
>> > -S
>> > On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: >> >> oh, nevermind about the dumbphone part. my understanding was a bit >> >> different than reality.
>> >> i guess i wouldn't mind; i learned a bunch of stuff in order to write >> >> my app with XML, so JSON won't kill me. if this means we get access >> >> to things like leaderboard & city changes i'm in. i hope both >> >> versions will be supported in parallel for a few weeks?
>> > -- >> > To post to this group, send email to foursquare-api@googlegroups.com
-- Abraham Williams | Community Advocate | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
Yeah, I'm probably doing something wrong. My app was a kludge to fill a void and then I hacked more functionality on to it... so yeah... probably doing something wrong. :-)
On Fri, Apr 2, 2010 at 11:13 PM, Abraham Williams <4bra...@gmail.com> wrote: > If your application requires a huge amount of work to switch from XML to > JSON you are doing something wrong. You should be able to switch out your > parser, modify you code to work with the new parser and be good to go.
> Abraham
> On Fri, Apr 2, 2010 at 19:51, Christopher Burris <ch...@chilitechno.com>wrote:
>> As part of v2 I'd like to see push-type notification to allow other >> non-iphone apps and api consumers to get notified when friends checkin, etc. >> :-)
>> Sure, come up with a clear migration path to a v2 which supports JSON >> only, keep the lights on v1 for at least a year - don't alienate those >> developers who have invested the time since the beginning with foursquare.
>> On Fri, Apr 2, 2010 at 10:37 PM, Brian Papa <bp...@me.com> wrote:
>>> My vote is for progress. The Foursquare team's time would be wasted on >>> supporting old stuff or options that would make only 20% of developers >>> happy. Make cool new stuff and make 80% of developers happy instead. :) >>> Every platform has API options for JSON and OAuth (aren't some even >>> Foursquare-specific?) so it shouldn't be that hard for devs to incorporate.
>>> Do JSON only and OAuth only for /v2. Continue to keep the lights on for >>> /v1 for some amount of time, maybe a year. If apps pointing to /v1 can't >>> upgraded in a year's time, then to be honest I wonder how interesting such a >>> rarely upgraded app would be in the first place. To be nice, track which >>> apps continue to hit /v1 stuff that's deprecated, and reach out to those >>> devs outside of the mailing list.
>>> Other thing I'd like to see, and this is just silly and doesn't have much >>> to do with /v2, but it'd be super handy if the API doc page had an >>> alphabetized list of links to anchors on the page. I always either get lost >>> scrolling or fail to command + F through because I forget the exact method >>> name.
>>> On Apr 2, 2010, at 8:15 PM, sabernar wrote:
>>> > -2
>>> > JSON wasn't reliable for v1 (malformations would cause parsers to crap >>> > out), so early on we had to switch to XML. You're forcing everyone >>> > who used XML and basic auth to rewrite everything. Any custom APIs >>> > that people developed will have to be completely rewritten. >>> > Personally, I think that if you're going to completely ditch half the >>> > API, we should have more notice. I don't know when you're planning to >>> > come out with v2, but wouldn't it be normal to deprecate those things >>> > for v2 and then ditch them completely in v3?
>>> > -S
>>> > On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: >>> >> oh, nevermind about the dumbphone part. my understanding was a bit >>> >> different than reality.
>>> >> i guess i wouldn't mind; i learned a bunch of stuff in order to write >>> >> my app with XML, so JSON won't kill me. if this means we get access >>> >> to things like leaderboard & city changes i'm in. i hope both >>> >> versions will be supported in parallel for a few weeks?
>>> > -- >>> > To post to this group, send email to foursquare-api@googlegroups.com
> -- > Abraham Williams | Community Advocate | http://abrah.am > PoseurTech Labs | Projects | http://labs.poseurtech.com > This email is: [ ] shareable [x] ask first [ ] private.
> -- > To post to this group, send email to foursquare-api@googlegroups.com
> Yeah, I'm probably doing something wrong. My app was a kludge to fill a > void and then I hacked more functionality on to it... so yeah... probably > doing something wrong. :-)
> On Fri, Apr 2, 2010 at 11:13 PM, Abraham Williams <4bra...@gmail.com>wrote:
>> If your application requires a huge amount of work to switch from XML to >> JSON you are doing something wrong. You should be able to switch out your >> parser, modify you code to work with the new parser and be good to go.
>> Abraham
>> On Fri, Apr 2, 2010 at 19:51, Christopher Burris <ch...@chilitechno.com>wrote:
>>> As part of v2 I'd like to see push-type notification to allow other >>> non-iphone apps and api consumers to get notified when friends checkin, etc. >>> :-)
>>> Sure, come up with a clear migration path to a v2 which supports JSON >>> only, keep the lights on v1 for at least a year - don't alienate those >>> developers who have invested the time since the beginning with foursquare.
>>> On Fri, Apr 2, 2010 at 10:37 PM, Brian Papa <bp...@me.com> wrote:
>>>> My vote is for progress. The Foursquare team's time would be wasted on >>>> supporting old stuff or options that would make only 20% of developers >>>> happy. Make cool new stuff and make 80% of developers happy instead. :) >>>> Every platform has API options for JSON and OAuth (aren't some even >>>> Foursquare-specific?) so it shouldn't be that hard for devs to incorporate.
>>>> Do JSON only and OAuth only for /v2. Continue to keep the lights on for >>>> /v1 for some amount of time, maybe a year. If apps pointing to /v1 can't >>>> upgraded in a year's time, then to be honest I wonder how interesting such a >>>> rarely upgraded app would be in the first place. To be nice, track which >>>> apps continue to hit /v1 stuff that's deprecated, and reach out to those >>>> devs outside of the mailing list.
>>>> Other thing I'd like to see, and this is just silly and doesn't have >>>> much to do with /v2, but it'd be super handy if the API doc page had an >>>> alphabetized list of links to anchors on the page. I always either get lost >>>> scrolling or fail to command + F through because I forget the exact method >>>> name.
>>>> On Apr 2, 2010, at 8:15 PM, sabernar wrote:
>>>> > -2
>>>> > JSON wasn't reliable for v1 (malformations would cause parsers to crap >>>> > out), so early on we had to switch to XML. You're forcing everyone >>>> > who used XML and basic auth to rewrite everything. Any custom APIs >>>> > that people developed will have to be completely rewritten. >>>> > Personally, I think that if you're going to completely ditch half the >>>> > API, we should have more notice. I don't know when you're planning to >>>> > come out with v2, but wouldn't it be normal to deprecate those things >>>> > for v2 and then ditch them completely in v3?
>>>> > -S
>>>> > On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: >>>> >> oh, nevermind about the dumbphone part. my understanding was a bit >>>> >> different than reality.
>>>> >> i guess i wouldn't mind; i learned a bunch of stuff in order to write >>>> >> my app with XML, so JSON won't kill me. if this means we get access >>>> >> to things like leaderboard & city changes i'm in. i hope both >>>> >> versions will be supported in parallel for a few weeks?
>>>> > -- >>>> > To post to this group, send email to foursquare-api@googlegroups.com
>> -- >> Abraham Williams | Community Advocate | http://abrah.am >> PoseurTech Labs | Projects | http://labs.poseurtech.com >> This email is: [ ] shareable [x] ask first [ ] private.
>> -- >> To post to this group, send email to foursquare-api@googlegroups.com
-- Abraham Williams | Community Advocate | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
Late to the conversation, but consider this another +1 for JSON.
As for OAUTH, I'm ambivalent. Right now, we're using basic auth for Kingpin, but OAUTH has been on our todo since the beginning so we'll be finishing up that functionality ... eventually. I spent a couple of hours last week adding sniper shots, instead. That seemed more important to the gameplay.
I think a lot of folks will feel about OAUTH like I do. If I have to talk it to access the API, I will. Otherwise, I'll probably spend my efforts adding features.
On Fri, Apr 2, 2010 at 9:20 PM, Abraham Williams <4bra...@gmail.com> wrote: > Rofl! Well at least you are honest about it :-P
> On Fri, Apr 2, 2010 at 20:17, Christopher Burris <ch...@chilitechno.com>wrote:
>> Yeah, I'm probably doing something wrong. My app was a kludge to fill a >> void and then I hacked more functionality on to it... so yeah... probably >> doing something wrong. :-)
>> On Fri, Apr 2, 2010 at 11:13 PM, Abraham Williams <4bra...@gmail.com>wrote:
>>> If your application requires a huge amount of work to switch from XML to >>> JSON you are doing something wrong. You should be able to switch out your >>> parser, modify you code to work with the new parser and be good to go.
>>> Abraham
>>> On Fri, Apr 2, 2010 at 19:51, Christopher Burris <ch...@chilitechno.com>wrote:
>>>> As part of v2 I'd like to see push-type notification to allow other >>>> non-iphone apps and api consumers to get notified when friends checkin, etc. >>>> :-)
>>>> Sure, come up with a clear migration path to a v2 which supports JSON >>>> only, keep the lights on v1 for at least a year - don't alienate those >>>> developers who have invested the time since the beginning with foursquare.
>>>> On Fri, Apr 2, 2010 at 10:37 PM, Brian Papa <bp...@me.com> wrote:
>>>>> My vote is for progress. The Foursquare team's time would be wasted on >>>>> supporting old stuff or options that would make only 20% of developers >>>>> happy. Make cool new stuff and make 80% of developers happy instead. :) >>>>> Every platform has API options for JSON and OAuth (aren't some even >>>>> Foursquare-specific?) so it shouldn't be that hard for devs to incorporate.
>>>>> Do JSON only and OAuth only for /v2. Continue to keep the lights on for >>>>> /v1 for some amount of time, maybe a year. If apps pointing to /v1 can't >>>>> upgraded in a year's time, then to be honest I wonder how interesting such a >>>>> rarely upgraded app would be in the first place. To be nice, track which >>>>> apps continue to hit /v1 stuff that's deprecated, and reach out to those >>>>> devs outside of the mailing list.
>>>>> Other thing I'd like to see, and this is just silly and doesn't have >>>>> much to do with /v2, but it'd be super handy if the API doc page had an >>>>> alphabetized list of links to anchors on the page. I always either get lost >>>>> scrolling or fail to command + F through because I forget the exact method >>>>> name.
>>>>> On Apr 2, 2010, at 8:15 PM, sabernar wrote:
>>>>> > -2
>>>>> > JSON wasn't reliable for v1 (malformations would cause parsers to >>>>> crap >>>>> > out), so early on we had to switch to XML. You're forcing everyone >>>>> > who used XML and basic auth to rewrite everything. Any custom APIs >>>>> > that people developed will have to be completely rewritten. >>>>> > Personally, I think that if you're going to completely ditch half the >>>>> > API, we should have more notice. I don't know when you're planning >>>>> to >>>>> > come out with v2, but wouldn't it be normal to deprecate those things >>>>> > for v2 and then ditch them completely in v3?
>>>>> > -S
>>>>> > On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: >>>>> >> oh, nevermind about the dumbphone part. my understanding was a bit >>>>> >> different than reality.
>>>>> >> i guess i wouldn't mind; i learned a bunch of stuff in order to >>>>> write >>>>> >> my app with XML, so JSON won't kill me. if this means we get access >>>>> >> to things like leaderboard & city changes i'm in. i hope both >>>>> >> versions will be supported in parallel for a few weeks?
>>>>> > -- >>>>> > To post to this group, send email to foursquare-api@googlegroups.com
>>> -- >>> Abraham Williams | Community Advocate | http://abrah.am >>> PoseurTech Labs | Projects | http://labs.poseurtech.com >>> This email is: [ ] shareable [x] ask first [ ] private.
>>> -- >>> To post to this group, send email to foursquare-api@googlegroups.com
> -- > Abraham Williams | Community Advocate | http://abrah.am > PoseurTech Labs | Projects | http://labs.poseurtech.com > This email is: [ ] shareable [x] ask first [ ] private.
> -- > To post to this group, send email to foursquare-api@googlegroups.com
> As part of v2 I'd like to see push-type notification to allow other > non-iphone apps and api consumers to get notified when friends checkin, etc. > :-)
> Sure, come up with a clear migration path to a v2 which supports JSON only, > keep the lights on v1 for at least a year - don't alienate those developers > who have invested the time since the beginning with foursquare.
> On Fri, Apr 2, 2010 at 10:37 PM, Brian Papa <bp...@me.com> wrote: > > My vote is for progress. The Foursquare team's time would be wasted on > > supporting old stuff or options that would make only 20% of developers > > happy. Make cool new stuff and make 80% of developers happy instead. :) > > Every platform has API options for JSON and OAuth (aren't some even > > Foursquare-specific?) so it shouldn't be that hard for devs to incorporate.
> > Do JSON only and OAuth only for /v2. Continue to keep the lights on for /v1 > > for some amount of time, maybe a year. If apps pointing to /v1 can't > > upgraded in a year's time, then to be honest I wonder how interesting such a > > rarely upgraded app would be in the first place. To be nice, track which > > apps continue to hit /v1 stuff that's deprecated, and reach out to those > > devs outside of the mailing list.
> > Other thing I'd like to see, and this is just silly and doesn't have much > > to do with /v2, but it'd be super handy if the API doc page had an > > alphabetized list of links to anchors on the page. I always either get lost > > scrolling or fail to command + F through because I forget the exact method > > name.
> > On Apr 2, 2010, at 8:15 PM, sabernar wrote:
> > > -2
> > > JSON wasn't reliable for v1 (malformations would cause parsers to crap > > > out), so early on we had to switch to XML. You're forcing everyone > > > who used XML and basic auth to rewrite everything. Any custom APIs > > > that people developed will have to be completely rewritten. > > > Personally, I think that if you're going to completely ditch half the > > > API, we should have more notice. I don't know when you're planning to > > > come out with v2, but wouldn't it be normal to deprecate those things > > > for v2 and then ditch them completely in v3?
> > > -S
> > > On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: > > >> oh, nevermind about the dumbphone part. my understanding was a bit > > >> different than reality.
> > >> i guess i wouldn't mind; i learned a bunch of stuff in order to write > > >> my app with XML, so JSON won't kill me. if this means we get access > > >> to things like leaderboard & city changes i'm in. i hope both > > >> versions will be supported in parallel for a few weeks?
> > > -- > > > To post to this group, send email to foursquare-api@googlegroups.com
I'll also take this opportunity to formally request venue name matching to register "real" checkins, instead of generic checkins when there is no Venue ID. Instead, if Venue ID is null, require city be passed in to avoid false positives in your matching.
On Apr 2, 3:14 pm, naveen <naveen...@gmail.com> wrote:
> we've been talking internally about v2 of the api for a couple of > weeks now
> we're doing a high level pass of things that work well and things we'd > like to see changed. we wanted to share a few of these sooner rather > than later so as to get your feedback
> - JSON-only: will be a great way to simplify everything: interface, > testing, documentation, etc.
> - OAuth-only: believe it or not, this is how the v1 api started -- and > then we backed off because we saw so much demand for a basic http auth > version. at the very least, how do you guys feel about a two-pass > system (use our auth exchange system to handoff login for oauth > tokens)? that is, all methods except the initial token exchange will > be oauth-enforced. because of the token exchange (which v1 already > supports [1]), your app will not have to do a complicated dance into > and out of a web view if it doesn't want to (or has a technically > difficult time doing so)
> - ...?
> you've all thrown out great ideas the last few months so i'm really > curious what other things you're thinking about. please follow up in > this thread with any and all comments!
> My vote is for progress. The Foursquare team's time would be wasted > on supporting old stuff or options that would make only 20% of > developers happy. Make cool new stuff and make 80% of developers > happy instead. :) Every platform has API options for JSON and OAuth > (aren't some even Foursquare-specific?) so it shouldn't be that hard > for devs to incorporate.
> Do JSON only and OAuth only for /v2. Continue to keep the lights on > for /v1 for some amount of time, maybe a year. If apps pointing to / > v1 can't upgraded in a year's time, then to be honest I wonder how > interesting such a rarely upgraded app would be in the first place. > To be nice, track which apps continue to hit /v1 stuff that's > deprecated, and reach out to those devs outside of the mailing list.
> Other thing I'd like to see, and this is just silly and doesn't have > much to do with /v2, but it'd be super handy if the API doc page had > an alphabetized list of links to anchors on the page. I always > either get lost scrolling or fail to command + F through because I > forget the exact method name.
> On Apr 2, 2010, at 8:15 PM, sabernar wrote:
>> -2
>> JSON wasn't reliable for v1 (malformations would cause parsers to >> crap >> out), so early on we had to switch to XML. You're forcing everyone >> who used XML and basic auth to rewrite everything. Any custom APIs >> that people developed will have to be completely rewritten. >> Personally, I think that if you're going to completely ditch half the >> API, we should have more notice. I don't know when you're planning >> to >> come out with v2, but wouldn't it be normal to deprecate those things >> for v2 and then ditch them completely in v3?
>> -S
>> On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: >>> oh, nevermind about the dumbphone part. my understanding was a bit >>> different than reality.
>>> i guess i wouldn't mind; i learned a bunch of stuff in order to >>> write >>> my app with XML, so JSON won't kill me. if this means we get access >>> to things like leaderboard & city changes i'm in. i hope both >>> versions will be supported in parallel for a few weeks?
>> -- >> To post to this group, send email to foursquare-api@googlegroups.com
> On Apr 2, 2010, at 7:37 PM, Brian Papa <bp...@me.com> wrote:
> > My vote is for progress. The Foursquare team's time would be wasted > > on supporting old stuff or options that would make only 20% of > > developers happy. Make cool new stuff and make 80% of developers > > happy instead. :) Every platform has API options for JSON and OAuth > > (aren't some even Foursquare-specific?) so it shouldn't be that hard > > for devs to incorporate.
> > Do JSON only and OAuth only for /v2. Continue to keep the lights on > > for /v1 for some amount of time, maybe a year. If apps pointing to / > > v1 can't upgraded in a year's time, then to be honest I wonder how > > interesting such a rarely upgraded app would be in the first place. > > To be nice, track which apps continue to hit /v1 stuff that's > > deprecated, and reach out to those devs outside of the mailing list.
> > Other thing I'd like to see, and this is just silly and doesn't have > > much to do with /v2, but it'd be super handy if the API doc page had > > an alphabetized list of links to anchors on the page. I always > > either get lost scrolling or fail to command + F through because I > > forget the exact method name.
> > On Apr 2, 2010, at 8:15 PM, sabernar wrote:
> >> -2
> >> JSON wasn't reliable for v1 (malformations would cause parsers to > >> crap > >> out), so early on we had to switch to XML. You're forcing everyone > >> who used XML and basic auth to rewrite everything. Any custom APIs > >> that people developed will have to be completely rewritten. > >> Personally, I think that if you're going to completely ditch half the > >> API, we should have more notice. I don't know when you're planning > >> to > >> come out with v2, but wouldn't it be normal to deprecate those things > >> for v2 and then ditch them completely in v3?
> >> -S
> >> On Apr 2, 4:43 pm, TJ <tjconne...@gmail.com> wrote: > >>> oh, nevermind about the dumbphone part. my understanding was a bit > >>> different than reality.
> >>> i guess i wouldn't mind; i learned a bunch of stuff in order to > >>> write > >>> my app with XML, so JSON won't kill me. if this means we get access > >>> to things like leaderboard & city changes i'm in. i hope both > >>> versions will be supported in parallel for a few weeks?
> >> -- > >> To post to this group, send email to foursquare-api@googlegroups.com
+1: Considering security, its better to deprecate basic auth.
> - ...?
- I strongly want new API to support these... - registering new account - retrieving shorten url like "http://4sq.com/5ojxJ0" from venue id - retrieving count of "YOUR VISITS" displayed in venue page - retrieving data for "STATS" displayed in http://foursquare.com/stats/$username
> we've been talking internally about v2 of the api for a couple of > weeks now
> we're doing a high level pass of things that work well and things we'd > like to see changed. we wanted to share a few of these sooner rather > than later so as to get your feedback
> - JSON-only: will be a great way to simplify everything: interface, > testing, documentation, etc.
> - OAuth-only: believe it or not, this is how the v1 api started -- and > then we backed off because we saw so much demand for a basic http auth > version. at the very least, how do you guys feel about a two-pass > system (use our auth exchange system to handoff login for oauth > tokens)? that is, all methods except the initial token exchange will > be oauth-enforced. because of the token exchange (which v1 already > supports [1]), your app will not have to do a complicated dance into > and out of a web view if it doesn't want to (or has a technically > difficult time doing so)
> - ...?
> you've all thrown out great ideas the last few months so i'm really > curious what other things you're thinking about. please follow up in > this thread with any and all comments!
I agree with Takeuchi Pomu. If you are using basic auth to get your oauth keys then you seem to be giving up a bit in your security policy. One of the great things about oauth is that you only give you password to 4sq and NOT "joe blow's client". I'm against basic in that sense.
However, I haven't inserted my oauth flow in my client yet so I'm sure I'll be loving basic in about 2 days.
Still +1 for oauth.
And I agree with what Abraham was saying. If you have to rewrite your whole app because of the network messaging protocol you may need to abstract some of that out a bit more.
+1 for JSON
On Apr 3, 9:26 am, TAKEUCHI POMU <pomu0...@gmail.com> wrote:
> +1: Considering security, its better to deprecate basic auth.
> > - ...?
> - I strongly want new API to support these... > - registering new account > - retrieving shorten url like "http://4sq.com/5ojxJ0" from venue id > - retrieving count of "YOUR VISITS" displayed in venue page > - retrieving data for "STATS" displayed inhttp://foursquare.com/stats/$username
> > we've been talking internally about v2 of the api for a couple of > > weeks now
> > we're doing a high level pass of things that work well and things we'd > > like to see changed. we wanted to share a few of these sooner rather > > than later so as to get your feedback
> > - JSON-only: will be a great way to simplify everything: interface, > > testing, documentation, etc.
> > - OAuth-only: believe it or not, this is how the v1 api started -- and > > then we backed off because we saw so much demand for a basic http auth > > version. at the very least, how do you guys feel about a two-pass > > system (use our auth exchange system to handoff login for oauth > > tokens)? that is, all methods except the initial token exchange will > > be oauth-enforced. because of the token exchange (which v1 already > > supports [1]), your app will not have to do a complicated dance into > > and out of a web view if it doesn't want to (or has a technically > > difficult time doing so)
> > - ...?
> > you've all thrown out great ideas the last few months so i'm really > > curious what other things you're thinking about. please follow up in > > this thread with any and all comments!
1. OAuth. Right now I'm developing an proof-of-concept using the HTTP Basic Auth. This allows me to explore my app idea without having to register for an OAuth token (which I plan to do once I finish). Removing the Basic Auth would add overhead to starting a new Foursquare app.
2. Friends' tips. Given an ID of one of my friend's, I want to be able to see all of their tips. Essentially, I have friends whose tastes I trust, and I want to 'follow' them to know whenever they find a new place to check out. This is kinda Twitter-like but with the location of the venue built into the app already.
3. Filter nearby tips by friends. FourSquare as it stands now gathers tips for each venue, but I want to see only the ones from my friends. I suppose I could still do this in software if you don't think this is a good idea.
I'm pretty excited about numbers 2) and 3). Feel free to contact me if you would like to chat more about them. : )
-- Daniel
On Apr 2, 6:14 pm, naveen <naveen...@gmail.com> wrote:
> we've been talking internally about v2 of the api for a couple of > weeks now
> we're doing a high level pass of things that work well and things we'd > like to see changed. we wanted to share a few of these sooner rather > than later so as to get your feedback
> - JSON-only: will be a great way to simplify everything: interface, > testing, documentation, etc.
> - OAuth-only: believe it or not, this is how the v1 api started -- and > then we backed off because we saw so much demand for a basic http auth > version. at the very least, how do you guys feel about a two-pass > system (use our auth exchange system to handoff login for oauth > tokens)? that is, all methods except the initial token exchange will > be oauth-enforced. because of the token exchange (which v1 already > supports [1]), your app will not have to do a complicated dance into > and out of a web view if it doesn't want to (or has a technically > difficult time doing so)
> - ...?
> you've all thrown out great ideas the last few months so i'm really > curious what other things you're thinking about. please follow up in > this thread with any and all comments!
> we've been talking internally about v2 of the api for a couple of > weeks now
> we're doing a high level pass of things that work well and things we'd > like to see changed. we wanted to share a few of these sooner rather > than later so as to get your feedback
> - JSON-only: will be a great way to simplify everything: interface, > testing, documentation, etc.
Definite +1
> - OAuth-only: believe it or not, this is how the v1 api started -- and > then we backed off because we saw so much demand for a basic http auth > version. at the very least, how do you guys feel about a two-pass > system (use our auth exchange system to handoff login for oauth > tokens)? that is, all methods except the initial token exchange will > be oauth-enforced. because of the token exchange (which v1 already > supports [1]), your app will not have to do a complicated dance into > and out of a web view if it doesn't want to (or has a technically > difficult time doing so)
+1 for not handing over login details, + for exchanging user details for oauth tokens as a necessary evil.
> - ...?
One of the things I'd love is a mass venue-fetching API method -- once a user starts using my service, the first thing we do is fetch a list of all of the venues they have visited. This can very very quickly eat through the API ratelimit, and isn't very friendly. Being able to specify a list of venue IDs that I want information for would be fantastic, e.g. /venue_batch?vids=123,456,789,12313
In fact, some sort of general batching API could be very handy, for any time we want to fetch a lot of data at once (e.g. venue info or user info). I can't think of any other examples at the moment (e.g. check-in history is already paged) but I'm sure there may be others.
In addition to the discussions on OAuth and XML, I have various other comments.
- JSON and ID numbers - I do wonder however why you must cast your id numbers to integers. PHP (and no doubt other languages) cope badly with large integers and unless I really need to perform arithmetic on these numbers, I will keep them as strings. Of course the json_decode function in PHP will cast BIGINTs to floating points and introduce potential problems. The fix I have been using for the Twitter API is to string-replace each JSON response before decoding (an unnecessary overhead) I can't think of many cases for performing arithmetic on user and venue IDs, so it would help a lot of IDs were cast as strings in your JSON responses. - yes it would add two bytes per value, but would make me and many other developers happy, I'm sure.
- JSONP - Do you have any plans to support a JSONP callback parameter and support some unauthenticated queries? This will open up the API to a whole other world of front end developers relying on cross-domain JavaScript techniques.
- Friend email addresses - I think you may come under fire for this at some point. "Showing my email to friends" also appears to mean "show my email to authenticated apps". Either you need to either state this more clearly to the public, or introduce a finer-grained privilege system like Facebook, or remove this field from the feeds.
- Feature request - Lists - For the app I'm developing I need to get checkins from a subset of venues by a subset of people. There appears no easy way to make this awkward intersection, other than grab lots of data and filter it myself. I'd love to see the Foursquare equivalent of Twitter lists, or perhaps just more extensible query methods for grabbing more flexible data sets.
