|
I actually spent the last two years writing a music app that integrated with the Soundcloud API to provide the bulk of the music content. To call their iOS SDK "neglected" is an understatement, but what I found worse was the opaque failure modes and restricted access provided by the official REST API. For example, Soundcloud provides artists with a switch to allow/forbid third-party clients using their API to access the audio streams of the songs they post. This restriction, naturally, doesn't affect the official Soundcloud apps. While it makes my app a second-class citizen for accessing Soundcloud content, I understand the motivation and reasoning for the feature. However, how does the Soundcloud API surface these restrictions? Through one of the dozens of flags it attaches to the json response it returns when you query for a track's metadata? Ha, no, all the various "track downloadable" and "streamable" flags are all set to true. Instead, it just returns a 404 when you try to fetch the data from the track URL...except when it started returning 401 instead (an admittedly more appropriate return code)...until it started returning 404 again. So as a developer, my only avenue for not surfacing non-playable tracks within my client was to attempt to download each track, catch any 4xx responses, ASSUME the reason is due to permissions rather than any other potential causes for 4xx errors, and hide the content within the app. I can understand Soundcloud's lack of enthusiasm for providing decent 3rd-party integrations, but if your external API is this much of a mess, I'd hate to see what you vend internally. The fact their permissions token provides zero granularity is not surprising to me at all. |
And here I thought their Roshi library looked pretty good. Maybe the talent is all on the backend there.