« Resources are concepts for the clientCherryPy for Python 3000 »



Permalink 07:40:00 pm, by fumanchu Email , 342 words   English (US)
Categories: IT


Interesting timing on Joe Gregorio's latest foray. Lately, I've been URI-ifying all the JSON calls which etsy.com's PHP layer makes to the back end (partly with the hope that that API would be opened up to the public someday, but that isn't currently a business need). Even though the company is bucking the mainstream quite successfully, the site itself is pretty typical e-commerce. Here's what I ended up with.

Out of 298 URI's (not counting querystring variants):

  • 40 are collections which support POST to add a subordinate item. Some of these are "top-level" object collections, and some are subordinate collections of data pertaining to single "objects" (e.g. /users/{user_id}/images/)
  • 37 are collections which support GET to return aggregated info on all, or a subset of, their members, sometimes with search params passed in the querystring.
  • 47 are traditional "objects" which support GET/PUT/DELETE on a URI of the form: /collection/subcollection/{id}, and tend to map to a database row (although many of those are virtual, being split in practice over several tables).
  • 92 are URI's which GET/PUT/DELETE "object attributes", usually a single scalar each, which tend to map to single database cells. Several of these have side effects when you set/delete them.
  • 34 are of the form /collection/count.
  • 31 are of the form /collection/ids/.
  • 20 are of the form /collection/count_and_limited_ids, which is perhaps a quirk of our architecture; at some point, I'd like to see how splitting these each into 2 calls affects performance.
  • 6 are RPC-style POST URI's which I haven't had time to refactor into real noun-y resources.
  • 2, I'm sad to say, are of the form DELETE /collection/{id}/cache

The URI space for this API is pretty sparse right now--these URI were simply created to replace an existing RPC-style space of procedure names. And it's essentially a single data point. However, I think it's pretty representative of e-commerce needs for RESTful JSON. One lesson might be that pagination (count and ids) should be addressed in any coordinated protocol effort.


Comment from: BradK [Visitor]

This is what I like about CouchDB, which I've started working with lately. REST JSon API is the only way to talk to the DB. Seems like a brilliant choice. How did you implement all of your API's? Did you use any particular framework or is it just hand built PHP?

08/22/08 @ 11:32
Comment from: fumanchu [Member] Email

It's Python, actually. We started with Twisted but had to abandon that once we did some load tests.

08/24/08 @ 18:02

Leave a comment

Your email address will not be revealed on this site.

Your URL will be displayed.

Please enter the phrase "I am a real human." in the textbox above.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)
August 2020
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          


The requested Blog doesn't exist any more!

XML Feeds

powered by b2evolution free blog software