Writing a module to abstract a REST api

[Joseph L. Casale]

> Well, I would be interested in seeing such a module as well.
> 
> Most modules and frameworks, I know, providing REST and interacting with
> REST are more like traditional SOAP-like web services. You got your
> functions which have a 1-to-1 correspondence with some resource URLs and
> that's it.
> 
> Actually REST is far more flexible than that, thus I still would love to
> see an authentic REST module.

So a design pattern I use often is to create Python objects to represent
objects returned from what ever api I am abstracting. For example I
might create named tuples for static data I dont intend to change or
for an object I can both query for and create, I might build a class to
represent it.

The problem now comes from the following:

# foo now contains a handle to the remote api.
foo = InstanceOfApiWrapper()

# queues is a container of Queue classes.
queues = foo.get_queues()

queue = queues[0]
queue.delete()

In this case its possible for foo (InstanceOfApiWrapper) to inject a reference
to itself so the delete() can actually make the call.

# I want to create a queue from scratch...
disparate_queue = Queue(x, y, z)
# Now what happens? No handle to an api?
disparate_queue.delete()

An alternative is:
foo.delete_queue(disparate_queue)

That's not a pattern I prefer, what facilities in Python provide for a workaround
here?

One option is to put everything in one module and use globals. If the handle is
initialized it'll just work.

Problem with that is its not thread safe (without work) and I subscribe to
one object per file (bloody hard with Python's import/load procedure.

This is a design pattern I have struggled with in the past.
jlc