I like the "PUT" in the example below. One of the things that makes the requests library feel so clean is the direct mapping of HTTP verbs to method names. For a thin wrapper around a REST(ish?) service, the same things makes sense to me. Just use the HTTP verbs directly as method names.
On Thu, Apr 25, 2013 at 5:31 PM, william <[email protected]> wrote: > I would go with: > > Resource(object_parameters) # for a pythonic interface or > resource.put(object_parameters) # for a light wrapper around the REST > service > > To me, store has far to much baggage. > > > > On Thu, Apr 25, 2013 at 10:04 AM, Christopher Bare < > [email protected]> wrote: > >> Thanks for the good advice! Jim's comment about being explicit about the >> actor (in this case, my service wrapper) resonated with me, so I'm leaning >> towards: >> >> rest_service.store(my_object) >> >> The soundcloud thing is still around, just at a different URL ( >> https://github.com/soundcloud/python-api-wrapper) that the one linked by >> Alex Martelli. It's a pretty good example, probably worth spending some >> time reading. >> >> Thanks! >> >> - Chris >> >> >> >> On Wed, Apr 24, 2013 at 9:10 PM, Toby Champion >> <[email protected]>wrote: >> >>> ... except that was 4 years ago and two of his three examples have >>> broken links. D'uh. >>> >>> >>> On 4/24/13 9:08 PM, Toby Champion wrote: >>> >>> Alex Martelli answers this SO question on this topic: >>> >>> http://stackoverflow.com/questions/1288198/can-someone-suggest-a-well-designed-python-wrapper-of-a-rest-api >>> >>> Toby >>> >>> On 4/24/13 8:25 PM, Jim Gray wrote: >>> >>> You usually want to follow the pattern actor.action(data) and not >>> data.action(). Better grammar and no confusion about which actor performs >>> action. >>> >>> It is also more DRY and more friendly to duck typing. Which objects can >>> .store()? >>> >>> If you really want to do it the second way, consider using decorators >>> such that my_object inherits the relevant bits from rest_service. >>> >>> Jim >>> >>> >>> >>> >> >
