search

metabrainz / web-service-v3-design

A collaborative specification for the third version of the MusicBrainz web service
2 stars 1 forks source link

Should we reduce response size by using relative urls? #12

Open warpr opened 12 years ago

warpr commented 12 years ago

In each of the example responses in the document you've used full URLs. In responses with many links (e.g. a compilation album with many tracks and featured artists) this could be a considerable percentage of the response size.

Possible solutions:

  1. Set the HTTP 1.1 Content-Base header to "https://musicbrainz.org/ws/3/" and use links relative to that in the response body (e.g. "aliases": "/artist/:mbid/aliases". ref.: http://tools.ietf.org/html/rfc2068#section-14.11)
  2. Use absolute urls without a host (e.g. "aliases": "/ws/3/artist/:mbid/aliases")
  3. Only support gzipped responses, i.e. mandate that clients support gzip compression

Should we adopt one of these solutions?

ocharles commented 12 years ago

Could you outline what you think the pros and cons of URIs vs absolute paths vs relative paths are?

warpr commented 12 years ago

Full URIs:

Pro: much easier for client authors to understand and use. Con: potentially large response size

URIs relative to Content-Base:

Pro: smaller response size Con: requires the use of a relatively obscure header. Con: it is not immediately clear to a client developer which strings are supposed to be links.

Absolute URIs:

Pro: response size not as small as relative URIs, but still considerably smaller than absolute URIs. Con: it is not immediately clear to a client developer which strings are supposed to be links.

Personally, I prefer full URIs, like you've already used. IF we decide to stick with full URIs, this github issue should still answer the question of whether to recommend or mandate gzipped responses.

ocharles commented 12 years ago

I don't think we should mandate gzip, but just encourage it. I mean, that's kinda how gzip is meant to work (a client says they can accept it, so we deliver it).

mayhem commented 12 years ago

+1 to ocharles' gzip comment.

Personally I like the Content-Base solution -- its really a very minor effort to grok and adapt to this solution. So, I vote for 1, with a limited dose of 3.

ocharles commented 12 years ago

I vote for full URIs, not Content-Base. I'm not convinced that the size of the response truly warrants this level of optimization yet. I like the clarity that things are absolutely a link, and not just how text happened to be formatted.