Version 0.2 of the Bugzilla REST API has been released. New in this version:
- Read/write support for flags, groups, custom fields and comment privacy
- Access to all aspects of Bugzilla’s configuration with a new /configuration call
- Even more high-quality and comprehensive documentation
- Better logging so I can debug problems
Note that these new capabilities will not be available on the copy of the API pointed at bugzilla.mozilla.org until the upgrade :-( But in the mean time, you can test them on the staging server. Although that seems very slow at the moment.
I consider this the first version of the API with which you should be able to write a capable Bugzilla client of some sort. Let me know if you find stuff missing which would be required for this usage.
Lastly, there is now a Bugzilla component for you to file bugs in :-)
I’ve been looking forward to the configuration piece, but I haven’t been able to actually get it in a way that doesn’t look like a formatting problem.
It’s also a HUGE piece of data, I wonder if some sub-APIs would be good, like to just get the components. Which is what I’m interested in, I don’t mind that much which flags are on.
Doh, posted to soon. It’d be great if the docs had a simple XHR example just to make sure how to set the content type etc.
Axel: sure, we can do sub-APIs. Which bits are you most interested in?
For bugzilla.mozilla.org, it’s 129k of JSON data. You aren’t supposed to download it all that often, but it’s still a big hit to begin with. I’ll see if I can find good ways to provide a skeleton and allow you to query the rest incrementally.
Gerv
Removing all references to flags cuts the size of bugzilla.mozilla.org’s config down from 129k to 56k. On the other hand, Red Hat Bugzilla’s config (albeit in JS rather than JSON form) is 394k, and that doesn’t include flag information. They just have a _lot_ of components. Goodness knows how big it would be if each of those components had flag info attached.
But I’m not sure if anyone would actually need config information without the component stuff, so I’m not sure it makes sense to do a call which excludes that too. Perhaps we just need to make sure the web server and client both support gzip transport encoding…
Gerv