Discussion:
Ways of using and improving the API
Devin Weaver
2012-06-11 15:06:42 UTC
Permalink
Tracks has an API, That is good. It is a RESTful API, that is better. The
way I understand the current implementation is that the client requests a
list from the API. It then receives the entire list. Basically no different
then the index page but with XML instead.

This makes things quite versatile. However it also means that subsequent
requests will get the entire dump all over again. A solution would be to
allow a list of ID's to be posted to such a request and the server would
only return items that had changed, added, or deleted. Saving space on the
transfer of information.

I ask this because I was in the planning stage for an application that will
use the API to interact with Tracks. It will store a copy of the items
(pulled through the XML requests) as to allow a user to work on the items
offline and the "sync" back to the server. The only way I see this
happening is to add that functionality to the server code.

I'm asking whether the development community would be interested in such
features. In other words If I fork and pull-request my additions to the API
specs is the community interested OR does this go against the design
principles for Tracks?

(My app wold be written in JavaScript so I was planning to add json APIs to
this).
--
"Doing something is not enough. Doing it right is what we want" - Michael
Munger
Matt Rogers
2012-06-11 15:14:55 UTC
Permalink
I was planning on adding a JSON based API to Tracks at some point, so if
you get to it before me, then that's fine by me :-)

Thanks
--
Matt
Post by Devin Weaver
Tracks has an API, That is good. It is a RESTful API, that is better. The
way I understand the current implementation is that the client requests a
list from the API. It then receives the entire list. Basically no different
then the index page but with XML instead.
This makes things quite versatile. However it also means that subsequent
requests will get the entire dump all over again. A solution would be to
allow a list of ID's to be posted to such a request and the server would
only return items that had changed, added, or deleted. Saving space on the
transfer of information.
I ask this because I was in the planning stage for an application that
will use the API to interact with Tracks. It will store a copy of the items
(pulled through the XML requests) as to allow a user to work on the items
offline and the "sync" back to the server. The only way I see this
happening is to add that functionality to the server code.
I'm asking whether the development community would be interested in such
features. In other words If I fork and pull-request my additions to the API
specs is the community interested OR does this go against the design
principles for Tracks?
(My app wold be written in JavaScript so I was planning to add json APIs
to this).
--
"Doing something is not enough. Doing it right is what we want" - Michael
Munger
_______________________________________________
Tracks-discuss mailing list
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
Loading...