Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/mattdeboard/trello-py-api
A resource-oriented client for Trello's REST API
https://github.com/mattdeboard/trello-py-api
Last synced: 18 days ago
JSON representation
A resource-oriented client for Trello's REST API
- Host: GitHub
- URL: https://github.com/mattdeboard/trello-py-api
- Owner: mattdeboard
- Created: 2012-07-14T05:38:27.000Z (over 12 years ago)
- Default Branch: master
- Last Pushed: 2012-07-14T06:43:28.000Z (over 12 years ago)
- Last Synced: 2024-12-01T12:05:10.881Z (22 days ago)
- Language: Python
- Size: 105 KB
- Stars: 2
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.rst
Awesome Lists containing this project
README
=============
trello-py-api
=============trello-py-api is a client for Trello_\'s REST API. There are already a couple [1]_ [2]_ of working Python API clients for Trello, so why another?
The main reason is that I wanted to explore writing a REST API client without the concepts of ``Client`` objects or ``Connection`` instances. Those don't really fit how I think of REST APIs anymore. I'm just trying to figure out what a ``Resource``\-oriented REST API client would look like, and how it would behave. If a RESTful web service/REST API "is a collection of resources" [3]_, maybe the client should match that metaphor.
It doesn't seem like there's a consensus on what REST API clients should look like. That being said my brain did start churning when I read Google's `Client Design document `_. They use a ``Resource`` class as the center of gravity for their API client framework. At this point I'm dropping in some of the concepts of `django-tastypie `_ (mostly metaprogramming wrt ``Options`` metaclasses for ``Resource`` classes) and seeing how that shakes out.
I'd be interested in hearing feedback.
.. _Trello: http://trello.com
.. [1] `py-trello `_
.. [2] `trollop `_
.. [3] `Wikipedia entry on REST `_