Developer API

[johnmaguire]

Hi! I remember seeing this project a while ago and really loving it. I was wondering if:

1. You might be willing to incorporate a developer API into the project. (This would be great for an IRC bot plugin I plan to write soon, so people pasting Spotify / GMusic links won't annoy users of the other service.)
2. I see you haven't made a ton of changes to this project lately (I know how side projects go :)), so I was wondering, if point number 1 is acceptable, if you'd be interested in me trying to write this functionality and submitting a pull request. :)

Alternatively, I also see that I could use the endpoint used in the Chrome extension. Would you prefer that fact isn't utilized? (i.e. Should I assume that is meant only for internal use, and it would be rude to use?)

Thanks!

[kudos]

Thanks for the kind words! Sorry for the delay in getting back to you, I seem to have screwed up my notifications for personal projects.

I don't want to return machine readable data from an API, simply because the third-party API tokens I have have limits. I'd be happy for people to bring their own tokens somehow, whether it's per request or stored in the database. When stored in the DB you'd effectively be exchanging your collection of API tokens for a match.audio API token. Does that make sense?

In terms of using the same endpoint as the chrome extension, that's totally fine. The only reason it's not documented is for a lack of time.

[johnmaguire]

Pretty sure that all makes total sense. To reiterate for clarity:

1. You're not opposed to a machine-readable API, but the user would have to provide relevant API keys for whichever services you're/they're accessing (e.g. Spotify). And possibly this could be stored in a DB for developers so they can just pass along a match.audio API key and you can route as necessary.
2. It's fine to send users to the search page on match.audio, just don't automate scraping the response returned by the server.

Correct? :)

[kudos]

Correct :)