Why is restish object-oriented?
Mike S
It's quite nice, but I'm struggling with something. When looking at
bottle for example, it's easy to figure out what's going on when
looking at the code. You have the http methods with get and put and
post and et cetera, as decorators, and you can tell at a glance what
url dispatch maps to what functions. It's simple like that; url
dispatch to handler functions. With restish it seems there's this
notion of a resource and then children of resources and so on. It's
quite OOP. When looking at the code example it's not so straight
forward to figure out what's going on. This unsettles me a bit as one
of the attractions of a restful architecture is conceptual simplicity.
I'm not against OOP perse, but I have to admit that when looking at
the code it's not as clear at a glance as that of bottle's.
So, in case I'm missing out on something, what are the advantages of
such an OOP approach to rest? Thanks. :-)
Peter Russell
I'm not an author of restish, but I thought I'd reply anyway.
It's interesting that you describe restish as OO, because I'd almost
say the opposite!
At it's core restish is about resources. And quite simply all a
resource is is a callable (effectively a function) which takes a
request and a list of url segments, and returns one of three things:
* A response,
* A new resource
* A new resource and a new list of url segments.
There is a dispatch loop at which you can see at
https://github.com/ish/restish/blob/master/restish/app.py#L25 which
repeatedly calls resources until it gets a response to send back to
the client.
This is something that would be easily implemented (perhaps even more
easily) in a functional programming language such as Haskell or
Scheme.
I think the restish docs should probably explain this earlier and more
succinctly, because it's key to how restish works, and also rather
elegant (I think). You certainly have to agree that it's conceptually
simple!
The restish.Resource class is a clever way of defining a resource. It
has a __call__ method which looks through the annotated methods on the
class and inspects the request and url segments it has been given in
order to work out which one best applies. There's some advanced
Python magic involved in making that happen, but at the end of the day
the result is something you can treat as a function which returns a
value. Not so very OO!
You may be right that it's harder to work out which resource will end
up handling a request. The style of dispatching used by restish is
very dynamic, and in my view dynamism in programming always involves a
trade-off: Speed for flexibility, safety for power, and so on.
However I'm not familiar with Bottle, or really with restish, so I'll
leave it to someone else to suggest what the trade-offs are in this
particular case :-)
Thanks
Peter
> --
> You received this message because you are subscribed to the Google Groups "ish.io" group.
> To post to this group, send an email to is...@googlegroups.com.
> To unsubscribe from this group, send email to ishio+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ishio?hl=en-GB.
>
>
Barry Warsaw
>I think the restish docs should probably explain this earlier and more
>succinctly, because it's key to how restish works, and also rather
>elegant (I think). You certainly have to agree that it's conceptually
>simple!
That's one thing I love about restish, it's actually a quite thin layer, so
it's easy to understand and use.
The only other REST library I have extensive experience with is lazr.restful.
It's a fairly decent library for a heavily Zope-based application, but it's
incredibly complex, difficult to use, and impossible to debug. In comparison,
restish is clean, agile, reliable, and *predictable*. While it's true there's
no one place to look to understand how your resources are organized, it almost
doesn't matter, because the Python code you have to write is so simple and
regular, it's pretty easy to read.
restish is the backbone for Mailman 3's REST API. Because restish is so
transparent, it usually takes me just a few minutes to add a new resource,
with tests and documentation. What also convinces me is how easy it is for
outside contributors to provide patches that extend the url space, or add a
new POST method, etc. There's almost no guesswork in what's going on, which
is a good thing. :)
As to whether it's OOP or not, as Peter says, it kind of is and kind of
isn't. Certainly, my own organization of resources is object-based, but like
Peter, I don't see restish *itself* as imposing much of an OOP structure on my
code, unlike lazr.restful for example.
(Aside: one of these days I'll get off my butt and submit patches for a few
key things I think are missing from restish, and which I've added in Mailman
3. E.g. a @PATCH decorator, a no_content() response, and support for
collections and etags. But we're really talking like less than 100 lines of
code, which is another testament to how nice restish is.)
Cheers,
-Barry