Web service feedback

[Robert Kaye]

I'm looking for some web service feedback. If you've used our web  
service, please read this:

    http://blog.musicbrainz.org/?p=409

--

--ruaok      A village in Texas has its idiot back!

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net


_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Kuno Woudt-2]

On Wed, Oct 14, 2009 at 05:13:55PM -0700, Robert Kaye wrote:
> I'm looking for some web service feedback. If you've used our web  
> service, please read this:
>
>     http://blog.musicbrainz.org/?p=409

That blog post currently has 0 comments, even though there were four
comments earlier today, what happened?

-- kuno.

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Paul C. Bryan]

And I just got the following error when I attempted to submit a comment:

"Sorry, but your comment has been flagged by the spam filter running on
this blog: this might be an error, in which case all apologies. Your
comment will be presented to the blog admin who will be able to restore
it immediately. You may want to contact the blog admin via e-mail to
notify him."

For posterity, here is the comment I submitted:

"Well, the last.fm approach seems to be non-RESTful, whereas the current
MB API is. If you adopted this, you’d no longer be providing a uniform
interface to a taxonomy of resources, but rather apparently providing a
single endpoint for all queries. I could go into all of the downsides to
such an approach, but I presume those who designed the v1 API are alive
to such issues."

Paul

On Thu, 2009-10-15 at 18:35 +0200, Kuno Woudt wrote:

> On Wed, Oct 14, 2009 at 05:13:55PM -0700, Robert Kaye wrote:
> > I'm looking for some web service feedback. If you've used our web  
> > service, please read this:
> >
> >     http://blog.musicbrainz.org/?p=409
>
> That blog post currently has 0 comments, even though there were four
> comments earlier today, what happened?
>
> -- kuno.
>
> _______________________________________________
> MusicBrainz-devel mailing list
> MusicBrainz-devel@...
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Paul Taylor-9]

Paul C. Bryan wrote:Yes this happened to me this morning and my comment was

'Sorry but I don't understand the example, would be better if you showed
the two ways to get the same thing, the first is clearly looking up a
specific release group, not sure if the second is looking up a
particular album or searching for an album. Nor do I understand the
benefits of Lukas'es approach I'm sure there are some but I can't see
what they are, need more detail.
Purely on a practical level I would prefer to keep the existing method
because it will be easier for client applications to migrate, and
because you won't fix bug #5448 the existing V1 interface is going to be
essentially broken shortly after the NGS release.'

Paul

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

On Thu, Oct 15, 2009 at 7:28 PM, Paul Taylor <paul_t100@...> wrote:
> Sorry but I don't understand the example, would be better if you showed
> the two ways to get the same thing, the first is clearly looking up a
> specific release group, not sure if the second is looking up a
> particular album or searching for an album. Nor do I understand the
> benefits of Lukas'es approach I'm sure there are some but I can't see
> what they are, need more detail.

The example is not very good, as it doesn't provide equivalent
functionality. Equivalent query would be:

/ws/2/?method=mb.releaseGroup.getById&id=052c7adb-5e2d-3cf3-b303-6c2a7d3e5b1c&inc=releases

The reason why I prefer the RPC approach is because we have more data
than just the basic artist/release/etc entities. One example that came
up in the mmd2 discussion is having a <release-group-list> element in
<label>. Surely it would be useful to have a WS query that returns all
release groups for a label, but labels can't contain release groups
directly. I'd prefer of the XML schema for MusicBrainz metadata
matched the database schema. So instead of:

/ws/2/label/MBID?inc=releases and /ws/2/label/MBID?inc=release-groups

I'd prefer explicit requests that return only the information the user
want, without tweaking the main metadata XML schema:

/ws/2/?method=mb.label.getById&id=052c7adb-5e2d-3cf3-b303-6c2a7d3e5b1c
/ws/2/?method=mb.release.findByLabel&labelId=052c7adb-5e2d-3cf3-b303-6c2a7d3e5b1c
/ws/2/?method=mb.releaseGroup.findByLabel&labelId=052c7adb-5e2d-3cf3-b303-6c2a7d3e5b1c

Another reason are write operations. Currently you don't have many
options how to implement them, which leads to inconsistency:

 - to submit ISRCs to a track, POST to /ws/1/track
 - to submit PUIDs to a track, POST to /ws/1/track
 - to submit tags to a track, POST to /ws/1/tag

I think the end goal is to alow *any* write operations over the web
service. I think it would be much cleaner to implement for example
edit submissions with the RPC approach.

And another reason are micro APIs for very specific operations. For
example, there is a bug report about looking up artists by their
Wikipedia URLs. This is trivial to implement, but we don't have a
place where to put the code. It obviously can't be in
/ws/1/artist/MBID and it can't be in /ws/1/artist as that is reserved
for the search server. We could add a special case in /ws/1/artist,
but it seems cleaner to me to have a separate RPC method for it.

--
Lukas Lalinsky
lalinsky@...

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Robert Kaye]

On Oct 15, 2009, at 9:35 AM, Kuno Woudt wrote:

> That blog post currently has 0 comments, even though there were four
> comments earlier today, what happened?


The spam filter plugin didn't survive the recent upgrade -- I've  
updated the spam filter and approved all pending comments. Carry on!

--

--ruaok      A village in Texas has its idiot back!

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net


_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

[Robert Kaye]

On Oct 15, 2009, at 11:02 AM, Lukáš Lalinský wrote:
> I'd prefer of the XML schema for MusicBrainz metadata
> matched the database schema.

The blog post got a nice comment from CBT -- he points to:

    http://duncan-cragg.org/blog/post/strest-service-trampled-rest-will-break-web-20/

This post contains a number of really concrete arguments to NOT  
abandon REST. Compared to a purist desire (one I share, incidentally)  
to make the XML schema match the database schema, REST comes out ahead.

I would be willing to have the XML not adhere fully to the schema in  
an interest to maintain a RESTful web service. I would then go and  
define the XML schema to be the "transport schema" for communicating  
NGS data. I'm much happier compromising the purity of the XML schema  
expression than compromising REST.


> Another reason are write operations. Currently you don't have many
> options how to implement them, which leads to inconsistency:
>
> - to submit ISRCs to a track, POST to /ws/1/track
> - to submit PUIDs to a track, POST to /ws/1/track
> - to submit tags to a track, POST to /ws/1/tag

We can easily fix this inconsistency for v2 -- its quite easy to pick  
the right action based on the arguments that are provided in the URL.  
I'd be glad to fix this for v2.

> I think the end goal is to alow *any* write operations over the web
> service. I think it would be much cleaner to implement for example
> edit submissions with the RPC approach.

Our new edit system, as we previously discussed, will take small edits  
and bundle them together into an arbitrarily compound batch of edits.  
That makes it less than clear which resource these edits should be  
posted to. We could pick an arbitrary rule like "post edits to the  
first resource identified in a compound edit" or we could create a  
pseudo-resource like an "edit-queue". The former is a little  
arbitrary, while the latter is not as RESTy.

Either way, I can see us figuring out the proper semantics for this --  
we just need to open the discussion as we are doing now.

> And another reason are micro APIs for very specific operations. For
> example, there is a bug report about looking up artists by their
> Wikipedia URLs. This is trivial to implement, but we don't have a
> place where to put the code. It obviously can't be in
> /ws/1/artist/MBID and it can't be in /ws/1/artist as that is reserved
> for the search server.

We should just have the search server have an index for the URLs, so  
that the search server can handle these queries.



--

--ruaok      A village in Texas has its idiot back!

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net


_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

On Thu, Oct 15, 2009 at 10:39 PM, Robert Kaye <rob@...> wrote:

>> Another reason are write operations. Currently you don't have many
>> options how to implement them, which leads to inconsistency:
>>
>> - to submit ISRCs to a track, POST to /ws/1/track
>> - to submit PUIDs to a track, POST to /ws/1/track
>> - to submit tags to a track, POST to /ws/1/tag
>
> We can easily fix this inconsistency for v2 -- its quite easy to pick
> the right action based on the arguments that are provided in the URL.
> I'd be glad to fix this for v2.

Picking the right action based on the arguments is exactly what I'm
proposing. That's not the REST way of doing things. The REST way would
be sending POST requests to /ws/1/isrc, /ws/1/puid.

--
Lukas Lalinsky
lalinsky@...

_______________________________________________
MusicBrainz-devel mailing list
MusicBrainz-devel@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel