1223643 - Spec API for TV marketplace

Status: RESOLVED FIXED

(Marketplace Graveyard :: API, defect, P1)

Description

[David Durst [:ddurst]]

This is both a bug and a milestone: by this point in the project we should be able to specify the API (in rtd) sufficiently that a mock API can be used by the front-end.

Comment 1

[Josh Cheng [:josh]]

Hi David, Hi Allen,
Do you have any update on this bug? We need this spec for marketplace front-end.
Thanks

Comment 2

[Allen Short [:ashort]]

I've added the URLs and some description here:
http://firefox-marketplace-api.readthedocs.org/en/latest/topics/tv.html

These are TV-specific variants of the general app/search APIs and should behave mostly the same -- they leave out some fields and the search filters to apps/websites approved for TV. Please let me know if anything needs clarification or changes.

Comment 3

[Allen Short [:ashort]]

Let me know if you have any questions.

Comment 4

[Josh Cheng [:josh]]

Hi Joseph, Hi Evelyn,
Could you please help to review the marketplace API for TV?
Thanks

Comment 5

[Evelyn Hung]

Joseph, from your code I see you are using '/api/v2/fireplace/multi-search/' already. Is it intentional?

Comment 6

[David Durst [:ddurst]]

:ashort -- can we update the docs to specify the fields? It will be hard for QA to verify the responses if they don't know which fields to expect.

Comment 7

[Allen Short [:ashort]]

docs updated 
https://github.com/mozilla/zamboni/commit/d0009f2c6420dddf79ee1360c608ec5e216fbf19

Comment 8

[Joseph Yeh [:joseph]]

Hi Allen,

I try the new API for TV (/api/v2/tv/multi-search/) and have some questions about it:


1. In the API for fireplace (/api/v2/fireplace/multi-search/), there is an attribute called 'slug' for every webapps and websites. But in the API for TV, I found that only webapps have attribute 'slug', websites did not. Is this intented or a bug?

2. I followed the code in fireplace to use defer blocks and use attribute 'slug' as the key (like {% defer (url=endpoint, as='app', key=slug) %}). If Question 1 listed above is intentional, I may have to change the key for every app since there is no key for websites. In this case, is using attribute 'id' as the key a good choice? Doesn't matter if Question 1 is a bug.

3. For webapps, I can find preview image url in the attribute 'previews', but for websites, there is no attribute 'previews' other than 'promo_imgs'. Furthermore, most of the values in 'promo_imgs' are empty. Is my understanding correct?

4. For websites, there are attributes 'url' and 'tv_url'. I found the document says 'tv_url' might be null. Is this means that I will have to open 'tv_url' if it exist and open 'url' if it does not? 


Just to make sure if any of my understanding is wrong. Thanks :)


(BTW, webapp and website listed above refer to their 'doc_type')

Comment 9

[Allen Short [:ashort]]

1. Our data doesn't include slugs, apparently. The fireplace api created a slug from the website id since the existing code expected one.

2. Keying by id seems fine to me, or by url. 

3. Previews got left in by mistake, sorry. Promo images are the correct thing to display, and when I generated some test data I don't think I added any images for that. I'll see about correcting that tomorrow.

4: tv_url and url will always be the same, there was some question of whether websites would be used for multiple devices and might have different urls for different form factors, but that isn't going to happen at this point. 

It might help you to know that so far the data we've been given only contain sites, not webapps.