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: 23 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-04-17T09:52:31.538Z (7 months 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 `_