byk / pyresto Goto Github PK

When using Pyresto against services that do not default to application/json, the client fails. With its current configuration, it also will fail against self-signed certificates.

Adding a parameter to the model to set the Accept header and SSL verification would enable access to a wider number of REST endpoints.

API documentation: https://dev.twitter.com/docs/api

Since the sample application (aka Github) and core.py were written more Github API oriented and that the api seems to be not using an api version number, we need to add that.

github api url: http://api.github.com/user/tunix
twitter api url: http://api.github.com/1/user/show/status.json?screen_name=tunix

/1/ in the latter url shows us the version number of twitter api.

(from https://travis-ci.org/berkerpeksag/pyresto/jobs/3699687)

test_iterator (tests.test_core.TestManyLazy) ... Exception RuntimeError: 'maximum recursion depth
exceeded in __subclasscheck__' in <type 'exceptions.AttributeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 
exceptions.AttributeError'> ignored
ok

test_iterator (tests.test_core.TestManyList) ... Exception RuntimeError: 'maximum recursion depth
exceeded in __subclasscheck__' in <type 'exceptions.AttributeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type
'exceptions.AttributeError'> ignored
ok

Pyresto should use httplib2 for its backend to exploit its advanced features like aggressive and proper caching(with memcached support), simplified authentication support and more elegant interface.

http://help.transifex.com/features/api/api-v2.html

Add HAL support for almost "definitionless" API library generation and traversal.

Create proper documentation about how pyresto works, how someone can use it to wrap a RESTFul interface and how the sample GitHub module is implemented.

When we create an empty model object, like

m = Model()

and then will try to get any attribute (which is obviously not exist)
we will get into infinite recursion call (in getattr)

but probably it should raise AttributeError instead?

Details are here: http://developer.github.com/v3/activity/notifications/

For the project to be future proof, it should be compatible with Py3k. If possible this should be done in a manner which does not break backwards compatibility with Python 2.7 but if necessary a new module/branch should be created.

Use abs metaclasses properly for a more robust interface.

Currently, we can strange errors with a broken connection object when the server does not return an "OK" response. This should be fixed ASAP.

I'd like to know how should I retrieve a list of objects from api:

for user in GitHub.User.list():
    print user

GitHub.User.get() seems to be only working with dict objects from response.

P.S. Thank you for releasing this library!

Some API's require authentication in someway to allow writes. Some require authentication even for reading so authentication support is crucial for success.

In the current implementation, when an api response provides a "continuation url" like GitHub does in the "Link" header under the name of "next", Model._rest_call method calls all the continuation urls iteratively and returns a merged result using the "+" operator. Although this approach is usually good, in some cases like getting all commits of a project, it takes too much time and usually unncessary resources since the needed subset of commits are usually the ones on the first "pages".

What needs to be done is to make this behavior at least optional or to switch to a "lazy loading" model where the current "WrappedList" approach may be replaced with an "iterator" approach. The first part needing change is the Model._rest_call method and the second part is the Many relationship.

Details are here: https://github.com/blog/1253-watcher-api-changes

The library must have a complete and through test suite to ensure it's robustness and quality.

All paths should automatically be converted into unicode strings to prevent any problems while formatting them with unicode strings. One such example is @leereilly's repos/branches/commits causing problems since there is at least one unicode character in the variables used to format paths.

Details are here: http://developer.github.com/v3/repos/statuses/

Going to implement twitter API for my learning process. Then I plan to implement #19 if time permits.

Hi,

This bug has been filed because a code search has revealed that code in this repository is using "BzAPI", the Bugzilla API proxy server at https://api-dev.bugzilla.mozilla.org/.

This service is due to be decommissioned. Fortunately, Bugzilla has a new native REST API which works somewhat similarly that you could use instead:
https://wiki.mozilla.org/Bugzilla:REST_API

Moving to that new API would require some porting work. If that seems like too much effort, fear not, because there is also a BzAPI compatibility layer built on top of the new API. Because it's compatible, using that should simply require a change of API endpoint.

Change:
https://api-dev.bugzilla.mozilla.org/latest/
(or https://api-dev.bugzilla.mozilla.org/1.3/)
to
https://bugzilla.mozilla.org/bzapi/

You should not expect the api-dev server to continue to work after Friday 14th November. So please test and migrate your production instance(s) over before then, either to the BzAPI compatibility endpoint or to the new native REST API.

Thanks for using BzAPI. It's been a great ride :-)

Gerv

Details are here: http://developer.github.com/v3/issues/

It seems Foursquare has different design goals and although I'm not into some of them like abandoning full REST interface compatibility(aka the verbs) it will be good if we can implement this API via Pyresto. This may require some internal changes in the core module which is okay if it persists compatibility with a better API like GitHub's.

The code should fully comply with PEP8 standards for wider adoption and to make it easier to contribute for other developers.

Using requests would help with below:

• Easier testing since we only need to stub methods on the module instead of trying to hijack classes.
• Easier authentication for APIs requiring this, including OAuth support.
• Simpler HTTP interfacing code.
• Easier API root definitions.

API documentation: https://confluence.atlassian.com/display/BITBUCKET/Using+the+bitbucket+REST+APIs;jsessionid=E2B58A666FD2B2A95BA9E1BF7B663236

Pyresto should have a directory layout to represent a package for it to be easily used in other projects(like github-badge =)).

Bugzilla has introduced a REST API recently. This can be implemented with pyresto too as a demonstration and may be to be used in other projects. Details are at https://wiki.mozilla.org/Bugzilla:REST_API