Facebook Feature Request: Event Search to Honour ‘center’ and ‘distance’ Parameters

Posted on in api, facebook

For quite a while now one feature I’ve felt was missing from the Facebook Graph API was searching for events by latitude and longitude along with a distance. You can currently issue a search for place objects, but the place object is the only one which honours the center and distance parameters.

I’ve filed a bug report for the feature request for Facebook to implement this and we’ll see how that progresses. If you would like to add your notes to the feature request or show your support you can do so at https://developers.facebook.com/bugs/288653361182652.

Expose Email Addresses via Twitter API

Posted on in api, twitter, twitter api

One of the most popular posts that I wrote previously for my blog was regarding the Twitter API and email addresses. That post has since been permanently archived and is no longer available It seems as though this topic is very popular among new developers to the Twitter ecosystem. In this post, I’m going to revisit that topic once again.

 

How do I get the email address of a user using the Twitter API?

This is a very simple question to answer. You can’t.

 

Why are email addresses not available via the Twitter API?

There is not a single reason why Twitter should hand over the email addresses of its users to anyone. Any application that you develop should explicitly ask the user the input their email address, clearly stating why you believe you need it.

User addresses are private, just like telephone numbers. The only need for email addresses to be exposed via the API is for spam harvesting which is a big no-no.

 

I want to keep my application users informed about changes

This is a reasonable thought, but consider the viewpoint of your users. The will follow the account associated with your application for news and updates. Users will also expect to find news, updates and important content via your application.

 

Will Twitter ever open up the API to disclose email addresses?

No, and that’s a good thing.

Why GeoCaching.com Needs an API

Posted on in api, geocache, geocaching, groundspeak

An all too common sight with the iPhone ApplicationA lot of what I talk about these days seems to be Geocaching related. The concept of Geocaching has long been around and at present the biggest central location of cache information is at geocaching.com which is owned by Groundspeak. The website, applications and tools are pretty average to use and no real changes have been made to the way that users interact with the site for a long time. The iPhone application is clunky at best and is a difficult to use at times. The reliability of the application over mobile connections is also questionable. All of the caching data is held by Groundspeak and although premium members can retrieve data via Pocket Queries (multiple caches in a single GPX/LOC file) and single file downloads (one cache per GPX/LOC).

There is no public API for developers or users to use. There is no systematic way other than scraping to fetch cache data – and this is against the terms of the site and services. There are many good reasons why Groundspeak should introduce a public developer API. It makes no difference if it is licensed and paid for, developers will still use it and it would boost the bottom line for Groundspeak.

 

Uses of an API

By opening up the data to developers, better applications can be created and users get choice. Choice is a very good thing. You only need to look at the enormous amount of Twitter applications that have made the ecosystem flourish and people can decide to use an application that provides them with the features that they want and less of what they don’t want.

 

Pushing Innovation

This fuelling of innovation can only help Groundspeak increase its revenues and expand Geocaching to a bigger audience. The more people that are using the API, site and products can only enhance what Groundspeak have to offer. Using the example of Twitter clients again, products that have implemented good ideas and functions often get copied: as the famous quotation goes “imitation is the highest form of flattery”. The problem with this is that at the present time Groundspeak are merely stagnating Geocaching for developers and in turn the end user.

 

Implementation

Any public facing API needs to be controlled in access and usage. This is to prevent aggressive over use and people not abiding by the terms of use. Leaning towards Facebook and Twitter’s APIs who both have very good usage policies and methods of dealing with over use by rate limiting, you can see effective throughput can be efficiently handled and scaled.

 

Free Use or Premium

The other side of providing the API is the cost of covering running the service. Access to it could be funded by providing to premium users only. If access if provided to premium users only, even without an increase in price the bottom line for Groundspeak would improve and a lot more users would pump money into the ecosystem by purchasing third party applications that would require premium memberships.

 

GCE:Standard

Any implementation of an API would likely provide either XML or JSON. An extension of this could be a new multi purpose format for cache information exchange, perhaps a new GeoCacheExchange:standard.

Twitter API and Email Addresses

Posted on in api, twitter

One thing that appears to be a recurring theme on the Twitter API development mailing list and in the IRC channel of Freenode is the question of getting access to a users email address. I’ve always found this frustrating and have never seen a good reason why a users email address should be given out via any API method. The following list contains the reasons that are most often given when you ask why an email address is desired:

  1. I’d Like to Contact the users of my application:
      See below.
  2. Auto-Notices & Spam:
      Not a chance.

It really is that simple. If you need a users email address then provide a settings page and ask them to enter it. Don’t think you can systematically fetch it from the API because you can’t, more to the point: I don’t think you’ll ever be able to.

And that’s a good thing.

Platform vs Web Site

Posted on in amazon, api, facebook, google, modern web, platform, twitter

Over the past six years we’ve seen major developments around the world in online services and computing. Traditional web sites such as Google, Amazon and eBay have now transformed into multinational platforms offering more than just a site to use. All of the services I’ve just named still provide their main web site, but isn’t it about time we started referring to them as platforms rather than sites. In my opinion, it is.

You can do so much more than simply search with Google or buy with Amazon and eBay. I don’t see the naming and references changing any time soon, but this is a thought I’d like to see come to fruition. The traditional roots of each of these large platforms can never be forgotten but through their own research, development and improvements they’re providing excellent services for the rest of the world to use.

In the more recent history, Twitter and Facebook have provided platforms for people to develop with which in turn created a boom for both enterprises. Its nice to see Facebook referring to their infrastructure and service as a platform, rather than a site. Perhaps others can follow suit, but I doubt it.

Google Latitude API Non-Existance

Posted on in api, geo, google, latitude, myglo.be

I’ve just written a request for more information from Google as I’m astounded to find no accessible API for Latitude. I find that completely shocking on their part.

I’ve looked on the AppSpot site and here in the group and I’ve not seen a definitive answer as such to this question. Is there an accessible API to update my location on Latitude? I already have my location via GPS elsewhere and would very much like to bridge this over the Latitude and update my location there.

I see that at present, this is not possible through existing Latitude services, however I’m interested in knowing whether or not Google plans to introduce this in future and if so – a possible time frame for doing so. I have an application that I would like to use this functionality in.

Scott.

You can see the actual post and follow it here.

Google Latitude API Non-Existance

Posted on in api, geo, google, latitude, myglo.be

I’ve just written a request for more information from Google as I’m astounded to find no accessible API for Latitude. I find that completely shocking on their part.

I’ve looked on the AppSpot site and here in the group and I’ve not seen a definitive answer as such to this question. Is there an accessible API to update my location on Latitude? I already have my location via GPS elsewhere and would very much like to bridge this over the Latitude and update my location there.

I see that at present, this is not possible through existing Latitude services, however I’m interested in knowing whether or not Google plans to introduce this in future and if so – a possible time frame for doing so. I have an application that I would like to use this functionality in.

Scott.

You can see the actual post and follow it here.

Google Latitude API Non-Existance

Posted on in api, geo, google, latitude, myglo.be

I’ve just written a request for more information from Google as I’m astounded to find no accessible API for Latitude. I find that completely shocking on their part.

I’ve looked on the AppSpot site and here in the group and I’ve not seen a definitive answer as such to this question. Is there an accessible API to update my location on Latitude? I already have my location via GPS elsewhere and would very much like to bridge this over the Latitude and update my location there.

I see that at present, this is not possible through existing Latitude services, however I’m interested in knowing whether or not Google plans to introduce this in future and if so – a possible time frame for doing so. I have an application that I would like to use this functionality in.

Scott.

You can see the actual post and follow it here.