This is Inside RadioTime, a website that gives Broadcasters, Developers, OEMs and Advertisers looking for the 411 on the RadioTime guide.

Proxy

Proxy or Download the RadioTime Service?

As an integrator with a product running on numerous devices, you may wish to proxy the RadioTime service with your own middle-tier service layer. Or instead, you wish to download a large portion of the guide to avoid service integration altogether. The arguments for either approach are usually along these lines:

  • Why do I need to make service calls? Isn’t the data the same for everyone?

No! Both the browse trees (organization) and the content within them (stations and shows) will be different depending on the location of the client, the language of the client, the time of day, the capabilities of the device, relevant broadcast restrictions, and other factors. Our service handles all of these transparently to give expertly crafted results. If you simply download a list of stations and streams, you have to replicate this organization and these rules to achieve a best-of-class product. Some have tried, with poor results. Let us focus on these hard parts so you can give undivided attention to your product.

  • I need a reliable, always-on service. I can’t trust a 3rd party with a critical component of my application.

RadioTime has demonstrated 99.7% reliability. We employ redundant hardware across redundant networks for stability, capacity, and failover. We monitor our services 24×7 and personally respond to issues from our partners within minutes in most cases (try that with Google or Amazon!). We are constantly working to improve our infrastructure with the latest tools and technology.

Numerous major brands trust RadioTime as a direct service partner, including Logitech, Sonos, Cisco, and many others.

  • We have thousands of devices and may scale to millions of requests per day. Most 3rd parties can’t handle that volume.

The RadioTime platform supports several million requests per day with capacity for many more. We carefully monitor our utilization and increase our footprint as needed to balance demand.

  • Direct service integration is too slow – I can’t have clients waiting on a 3rd party API.

Typical processing time for a service request in our platform is 1-15ms. Network latency can add anywhere from a few dozen to a couple hundred milliseconds. We support gzip compression to reduce bandwidth and speed data transfer. In practice, we have found with dozens of partners that the overhead of our API is insignificant compared to operations like stream tuning or even display rendering. Moreover, if you add a proxy in front of the RadioTime service, clients must wait for an additional “hop” before receiving content. This creates an even greater lag.

The reasons in favor of a direct integration are many:

  • Less complicated implementation
  • Benefit from new or improved features as we release them
  • Benefit from new localizations as we release them
  • Ability to intelligently filter, sort, browse content based on the specific user
  • Ability to receive insightful usage reports – we collect and can distribute a wealth of information about what your users are listening to, what’s popular, etc. Often this data is directly applicable to creating a better product.

Proxy Considerations

In the case where a proxy cannot be avoided, the following must be taken into account:

  • The proxy should not globally cache any content. The results for any given call will vary for any given user at any given time of day.
  • The proxy should send the originating client IP as an X-Forwarded-For HTTP header. This will allow us to provide a local experience.
  • The proxy should send a unique client device ID (like a serial number of MAC address) in the deviceId parameter of the OPML request.