Code review comment for lp:~paulliu/unity-scope-click/showratings

On Thu, Jan 9, 2014 at 3:41 PM, Michael Nelson
<email address hidden> wrote:
>
> If it's worth creating a separate API for click (with separate specs
> from what we already do for USC), then let's do that. If we want to
> re-use what we've already got for USC, let's do that. That decision
> isn't my call, but I do want to be able to support you whichever way
> that decision goes.

FWIW, I'm doing a quick branch which I'll give to Rodney tomorrow with
an example of a separate click review API (as part of the same
service). It won't take long, and would mean we don't have to release
software on the client that has hacks to fit in with existing services
for which it wasn't designed. It'll also have the benefit that it's
easy to separate later if we need to deploy the click review service
separately.

I'm doing the following, but we can make it exactly as we see fit so
just let me know:

To create a review, it's much the same:
POST /click/api/1.0/reviews/
with the json data (same as current, just without origin or distroseries)

To retrieve reviews for a specific application:
GET /click/1.0/reviews/en/com.ubuntu.developer.dholbach.webapp-bvg/

Or, if you'd prefer:
GET /click/1.0/reviews/?lang=en&package_name=com.ubuntu.developer.dholbach.webapp-bvg
(url-encoded)

The original reason that the existing API uses the former
non-query-param filters is because not all caches will reliably cache
uri's with query params, but perhaps that's not so important (or
relevant) now (I'm not a squid expert). The flexibility of the second
option is certainly nicer (and more standard). We can move other
features (moderation, +1's etc.) across easily as we need them too.

As an aside, I mentioned to beuno today that I'm pretty sure we'll
also want to update the search.apps.u.c search results to include the
review stats (at the least, the current rating for each app in the
results so the client can display the stars, and only request reviews
when needed).

Cheers,
Michael