Can someone suggest a well-designed Python wrapper of a REST API?

views:

302

answers:

+1 Q:

Can someone suggest a well-designed Python wrapper of a REST API?

I'm writing a new one (for Netflix), and am simply wondering if there are any great reference libraries for me to study.

In particular I'm looking for clever ways to express a single REST endpoint in code, which needs a least a URL, method, and params, and in the case of Netflix, information about the authentication level required.

To be clear, I am looking for idiomatic and well-written Python libraries covering REST APIs. If the library is blazing fast, but is difficult to use and/or poorly written, I'm probably less interested.

+2 A:

Is what you have in mind something like this, this and this? Because as you can see from these good examples there isn't exactly a perfect meeting of minds regarding the best style to use for the purpose, though the differences aren't terrible. Or do you want a discussion of the pros and cons rather than simply good examples as you ask?

Disclaimer: haven't really dug into the internals of these APIs to check whether they're "well written" -- I'm judging them strictly in terms of "how do they look from the outside". It seems to me that this is a good criteria -- if the implementation has some oopses, those can be fixed much more easily and seamlessly than if the API itself, i.e. the publically visible and published interface, does!-)

Alex Martelli 2009-08-17 14:35:08

I'm really looking for any and all best practices for writing a REST api wrapper. The public interface is certainly a very important part of that. Particularly I'm wondering when or if the end user should have to be aware of the URIs and method for each resource. I'll be checking out all three.

Triptych 2009-08-17 15:03:27

So the general point of agreements for designing such APIs has to be that the URI gets "composed" under the covers and the GET/POST/etc chosen accordingly, else you'd just be using bare httplib or so;-). But how much "thick glue" you want to layer on top of that is less obvious (my instinctive preference is almost always for thin rather than thick, heavily influenced by Raymond's great book "Zen of Unix Programming" or rather by much the same influences that led him to write it;-).

Alex Martelli 2009-08-17 15:27:47

Accepting this, with the idea that I'll be asking more specific questions about design decisions later on.

Triptych 2009-08-17 18:28:15

@Alex Martelli if you mean that clients will compose the URIs, then it is RPC, not REST. @Triptych If you want to use REST, the only URI that is hard coded into your client, and given in the API, is the entry-point URI. The rest are discovered through hypertext.

Wahnfrieden 2009-08-17 20:27:57

@Wahnfrieden. Last I checked, you needed to know the URI for each REST resource. What do you mean the URIs are "discovered through hypertext"? By "hypertext" do you mean HTTP? I'm not sure HTTP is even a necessary condition for RESTful services, nor am I aware of a canonical REST specification. Can you clarify what you're saying?

Triptych 2009-08-17 22:28:40

@Wahnfrieden, also, can you point me towards a REST API provider that does, in your view, perfect implement the REST specification.

Triptych 2009-08-17 22:29:18

No, if the client has all the URIs hard coded, then you have too much coupling between URIs and resources, and you violate a constraint of REST - your API is simply RPC. Hypertext isn't HTTP. HTTP is not necessary for REST (Fielding's dissertation doesn't even mention HTTP), but hypertext-driven APIs are. I suggest you read http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven As for a great example of a REST API, look at AtomPub, or Sun's Cloud API http://kenai.com/projects/suncloudapis/pages/Home

Wahnfrieden 2009-08-18 14:52:12

ansaurus

tags:

views:

answers:

Can someone suggest a well-designed Python wrapper of a REST API?

related questions