-
Bug
-
Resolution: Fixed
-
Normal
-
None
-
None
-
None
Hi,
Searching for artists, I use the following URL : http://musicbrainz.org/ws/2/artist?query=artist:"foo"&limit=10&fmt=json
The response look like :
{ "created" => "2013-11-10T07:52:48.173Z",
"count" => 506,
"offset" => 0,
"artist" => [...]
}
Accordingly to the doc, I expected to get an "artists" key instead of "artist".
[SEARCH-383] JSON return an array called 'artist' instead of 'artists'
@steveedson I've just learned this myself thanks to MB's blog ← I always keep attentive eye on these release notes (don't limit an a category, watch all posts) each time to know if some impacts for me. You can keep an eye on this source if (like me) you rely on some resources from MB, it's the easiest and best source for API or website changes.
From http://musicbrainz.org/doc/Development/JSON_Web_Service
"WARNING: This web service is available on the production server (musicbrainz.org/ws/2/), but should be not be considered stable. There are still some known bugs, and we may decide to make some small changes to the API as documented below"
That also applies to the search component of ws/2. So, no prior notice was given anywhere else because it is marked as a beta product and changes are to be expected.
Why has something like this been changed without any notice?
I implemented my application when the response was still returning the singular values. This was not noted as a bug anywhere.
So by "Fixing" this issue, its caused a bug in my application.
If an API has been configured to return a response in a particular format, regardless of grammatical issues, it either needs to
- Stick to that format
- Provide a versioned API
- Give plenty of notice to developers that the change will occur
Steve
Ah thanks for checking.
Now fixed with tests for all entities https://bitbucket.org/metabrainz/search-server/commits/f1dce7d78cb2dd74be34b649492cb02021b0d39d
There's several more, at least:
http://musicbrainz.org/ws/2/recording?query=recording:foo&fmt=json
Yeah I think I just missed artist, now fixed with test https://bitbucket.org/metabrainz/search-server/commits/02de43c44757ee15a24ce7478a30fdd950b29be6
This also applies to any other top-level list element, which should be pluralized; I haven't checked each one specifically.
This appears to only be a search bug, see e.g. http://musicbrainz.org/ws/2/artist?area=7c71f821-98a0-4f1b-bf6b-87fe1d6c89f0&fmt=json which properly pluralizes the top-level key.
Funnily, MBS itself fell into that trap, too.