Last Comment Bug 875536 - Make a special Fireplace API namespace
: Make a special Fireplace API namespace
Status: RESOLVED FIXED
p=1 [qa-]
:
Product: Marketplace
Classification: Server Software
Component: API (show other bugs)
: 1.0
: x86 Mac OS X
: P3 normal (vote)
: 2013-07-11
Assigned To: Allen Short [:ashort]
:
:
Mentors:
Depends on: 875547 875548
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-23 15:38 PDT by Andy McKay [:andym]
Modified: 2013-07-08 13:28 PDT (History)
2 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Andy McKay [:andym] 2013-05-23 15:38:49 PDT
There's a bunch of APIs for fireplace that are very fireplace specific. This calls are things that we don't expect other clients to make and are formatting their response in a way that we wouldn't normally expect. This makes it hard for fireplace, we can't change things quickly and hard for clients who expect things to happen in a certain way (the GET /apps/app/...) for example. Another is the home page (http://firefox-marketplace-api.readthedocs.org/en/latest/topics/home.html#get--api-v1-home-page-) which is returning a result exactly the way fireplace wants. If that design changes, we shouldn't change the api.

URLs that I think we should move:

/home/page/ > /fireplace/home/
/apps/app/(int:id)|(str:slug) > /fireplace/app/(int:id)|(str:slug) *
/search/featured/ > /fireplace/search/featured/


** /apps/app/ will stay where it is, its just that /fireplace/app/ will have the more expanded result that fireplace wanted (users, upsell etc)

Any others?

* /apps/rating/ contains user information, I'm tempted to fork it similar to /apps/app/


We'll need to move documentation and make clear that whilst clients can use this, we won't be worrying about changing things rapidly as the fireplace client needs change.

Note You need to log in before you can comment on or make changes to this bug.