-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API v2? #9
Comments
Would be happy to have you contribute. I've been thinking about refactoring the object/class hierarchy of the library anyway. |
Thanks for the reply. It's underway. The data structures returned by the API are different in v2, but that is largely transparent as far as the library is concerned, as it's just a wrapper. It does mean that significant code change is probably required by users of the wrapper, to update to v2 even after the wrapper has been updated. It therefore seemed logical for me to also update the object and method names to reflect those used by the new API, rather than try to make the wrapper compatible. I am not sure how strict I will be about this. If I get the chance to make the new version more consistent with the old without a lot of extra work, I'll probably do that. There are also a few places where the methods provided for the v1 API reflected API calls that no longer exist in the v2. In my initial release those methods will be gone and there will be new methods instead that reflect the new API. It should be possible to restore at least some of the old methods as a sort of emulation step afterwards. Any advice on how to add to the file headers to reflect that this is a complete overhaul by me based on the original structure, would be welcome. I presumably need to keep the entire original header but could insert attribution lines into it. |
I ended up building a wrapper from scratch based more closely on the v2 API. It's pretty minimal (240 lines of code right now) but it should work with all API functions and the usage is reasonably elegant. I built it on the clock on a project for a customer, hence the need to get it done fairly efficiently and not struggle for a long time with someone else's code. When I have figured out how to tidy it up for public viewing, I plan to release it. |
Got any news on that? Seems really interesting! |
Sorry for the lack of reply. I apparently am not getting emailed responses, which I will address. I hand over the project to the client shortly. The "library" is a single php file of about 250 lines (and uses the free Unirest library to do its http/REST). It allows usage like this, which you should be able to improvise if you look at the API: You have to hand roll the objects $fields and $party in the above example and there's no checking that you've done this correctly. Can anyone recommend what I need to do as a minimum to get the library out there for people to use?
Thanks! |
Is anyone looking at adapting this library to the v2 API? v1 expires in Jan.
I used this library for a lot of hacking with v1 and applied various local edits and fixes, but have never figured out how to collaborate on Github.
If no-one else steps forward, I think I am likely to have to hack together some adaptations to make it work with v2, keeping the current general approach and structure. I'd be happy to give the changes back to the community but I would probably need some pointers on how best to do that.
The text was updated successfully, but these errors were encountered: