search

seatgeek / api-support

A support channel for the SeatGeek Platform
9 stars 7 forks source link

[enhancement] ISNI support for artists #15

Closed slaght closed 8 years ago

slaght commented 8 years ago

Hi again, Recently, The Echo Nest announced the shutdown of their API and requesting all users migrate to Spotify. However, they are not migrating all of their useful features to the Spotify API. In particular, they are seemingly dropping support for Project Rosetta Stone, which you guys have had built in to your API.

Now, since the application I am building translates IDs across different services (MusicBrainz->SeatGeek), I am currently in a pickle with this API shutdown. Would you ever internally consider implementing another function like this, such as the ISNI database?

Cheers,

slaght commented 8 years ago

Update on this: it would also suffice to have more narrow query functionality, such as limiting artist query scope to just the artist names, or limiting event query scope to the performer name

josegonzalez commented 8 years ago

Woops, didn't notice this issue!

@BrandonSlaght What would the ideal api url look like for your narrow query functionality?

slaght commented 8 years ago

@josegonzalez Maybe something like https://api.seatgeek.com/2/performers?q=red+hot&scope=name (or events, or venues, ect) Where if scope is included, the query is treated as it currently is, searching through everything. However, I have never designed an API before so I have no clue if this violates your design or RESTful principles.

josegonzalez commented 8 years ago

I don't understand what the scope does in your query.

slaght commented 8 years ago

Scope would, for example, narrow the query to only searching for names matching the query, as opposed to searching in the name, event, and venue fields.

josegonzalez commented 8 years ago

Oh I see.

I don't think we can go down this route as it'll change the semantics of our search api (for both internal and external clients). Using the q argument to search performers is enough (it should bring up RHCP for that query you show) and then you can filter the events endpoint by that performer id.

I'll bring up internally the ISNI issue, but I don't think we'll implement a solution for this anytime soon.