> I did a full pass on the REST API I had and extracted a documented subset > that > should be easy to extend in the future. > > http://patchwork-freedesktop.readthedocs.org/en/latest/api.html > > A list of entry points is available, that's the basic documentation needed. > More will be added later (describe the 'related' GET parameter, how lists > of > objects work, ordering, some more details about the various fields, ...) > > On top of exposing the basic objects, later patches add the concept of > events > to the db and expose them in the API. The first event here is > 'series-new-revision', an event created when patchwork has received a new > version of a series. This event can be listened to (well, using polling > atm) to > trigger tests on an incoming series. > > FWIW, the REST API is documented using sphinxcontrib-httpdomain[1], a bit > quirky but does the job. > > -- > Damien > > [1] https://pythonhosted.org/sphinxcontrib-httpdomain/
I'm interested in hearing other peoples perspectives on this. I don't want to undermine or make little of anyone's work here and I really am a fan of the open API movement and REST in particular. However, as previously stated, there is an XML-RPC API available for use and it doesn't require adding a lot of new code that needs to be maintained, not to mention new libraries and the need to develop and distribute new clients. This particular change seems like a combination of reluctance to learn how XML-RPC APIs work and unwillingness to fix issues with the existing API. We could do everything that is accomplished in the first six patches of this series in approximately 50 lines of code. REST may be the current API du jour, but XML-RPC isn't the complicated beast that is SOAP. I honestly don't think REST brings enough to the table *for our use cases* to justify the move. Stephen _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
