Monthly Archives: April 2013

How to localize your API

Full disclosure: I was born and live in the USA, American English is my native language, and I spend USD every day. However, I work with customers in 18 countries and regions on five continents, and the list is getting bigger all the time.Internationalization localization and currency

Operating a business in the global market is not as trivial as it might seem, if you’ve never seen it through. Everyone not only speaks different languages and has different currencies (not to mention driving on the different sides of the road), but they also have different cultural norms. In many situations, we can merely provide raw values for dates and currency and avoid formatting. However, when content includes localizable information, especially dates and currencies, display formatting needs to be sensitive to the localized culture.

If you’re considering making the jump off of your own soil to the rest of the globe, hopefully this will give you some insights.

Continue reading “How to localize your API” »

Review: Google Glass API

Since Google’s announcement of Glass people have been wondering about the possible applications that can be built on it and how it might increase one’s productivity. Well, your wait is over now, because Google has recently released the documentation on how to interact with Glass through their Mirror API.

According to the documentation, the Google Mirror API “allows you to build web-based services, called Glassware, that interact with Google Glass”. Even better is the fact that this functionality doesn’t need that you run any code on Glass itself, since all interactions are done via RESTful endpoints.

Continue reading “Review: Google Glass API” »

How to Expose User Information

At a first glance you might think that offering an API method that returns information about your application users might not be a good idea. With the increasing usage of APIs for business related purposes you might fear that you’re giving away precious information about your customers.

photo by The Wide Wide World

But think again. If you give the right amount of information, applications built on top of your API will be able to offer a better service to your users. Your final user will have a better experience and that might turn out to generate more business for you.

Continue reading “How to Expose User Information” »

URL Design for RESTful Web Services

URL design discussions for RESTful web services often degrade into debates over pluralization and parameter names. There are a couple of principles I like to use to keep things simple.

1) Using your API should feel like using a filesystem

  • Endpoints used to create, list, and search for entities should look like directories, e.g. /users
  • Use a plural noun so it feels like a directory of users, not a user controller
  • Endpoints used to read, update, and delete individual entities should look like files, e.g. /users/charlie

Continue reading “URL Design for RESTful Web Services” »