Bugzilla:API Comparison: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 15: Line 15:


* List attachments for bug: /bug/<id>/attachment GET -- Bug.attachments
* List attachments for bug: /bug/<id>/attachment GET -- Bug.attachments
* Retrieve attachment: /attachment/<id> GET -- Bug.attachments
* Create new attachment: /bug/<id>/attachment POST -- Bug.add_attachment
* Create new attachment: /bug/<id>/attachment POST -- Bug.add_attachment
* Retrieve attachment: /attachment/<id> GET -- Bug.attachments


* Search for users: /user GET -- User.get
* Search for users: /user GET -- User.get
Line 85: Line 85:


* /bug/<id> GET -- Bug.get
* /bug/<id> GET -- Bug.get
Differences:
* The REST API does not support the experimental "permissive" boolean on requests. So it also returns an array of bugs, and does not return the "faults" array.
* The time tracking fields are defined as double in RPC, and Decimal in REST.
* The REST API returns User objects instead of email addresses.
* The REST API does not return "creation_date" or "modification_date" on flags.
* The REST API returns Group objects (with name and ID) instead of group names.
* The REST API includes attachment metadata by default. The RPC API does not include any attachment data at all.
* The REST API includes comments if you ask for them using field control. The RPC API does not include comments.
* The REST API does not return the "is_open" field.
* The REST API returns a "ref" field.
Other than that, field name compatibility is very good.


===Update bug===
===Update bug===


* /bug/<id> PUT -- Bug.update / Bug.update_see_also / Bug.update_tags
* /bug/<id> PUT -- Bug.update / Bug.update_see_also / Bug.update_tags
Differences:
* The REST API requires a valid "token" field.
* The REST API optionally does mid-air collision detection (by setting "last_change_time"). The RPC API does not.
* The REST API sends User objects instead of email addresses.
* The RPC API has an "add/remove/set" model (with "set" sometimes not implemented) for some multi-valued fields where the REST API simply has a "set" model. These are "blocks", "depends_on", "cc", "groups", "keywords" and "see_also".
* Adding comments via REST involves adding a hash to an array; in RPC, it's a simple hash (with "body" and "is_private" members).
* The RPC API has a mechanism for updating the privacy of existing comments - the comment_is_private hash. I'm not sure how the REST API handles that.
* The RPC API permits the setting of "remaining_time", which is Read Only in the REST API.
* The REST API uses the JSON "null" value to "reset to default" for assignee and QA contact, whereas the RPC API has special boolean fields "reset_assigned_to" and "reset_qa_contact".
* The RPC API returns much more info about the bug and the change than the REST API does.


===List comments for bug===
===List comments for bug===
Line 133: Line 159:


* /bug/<id>/attachment GET -- Bug.attachments
* /bug/<id>/attachment GET -- Bug.attachments
Differences:
* The RPC API can take either a list of bug IDs or a list of attachment IDs, and returns different structures depending on which you give. This REST API takes a single bug ID only.
* The REST API returns "ref", "bug_ref", and "encoding" (only "base64" supported) fields which the RPC API does not.
* The REST API returns "description"; the RPC API also returns it, but is moving to call it "summary"
* The REST API returns "attacher"; the RPC API also returns it but is moving to call it "creator"
* The REST API does not have "creation_date" and "modification_date" for flags.
* The RPC API returns a "last_change_time"; the REST API does not.
* The REST API does not return attachment data by default.
===Retrieve attachment===
* /attachment/<id> GET -- Bug.attachments
Differences:
* The RPC API can take either a list of bug IDs or a list of attachment IDs, and returns different structures depending on which you give. This REST API takes a single attachment ID only.
* The REST API returns "ref", "bug_ref", and "encoding" (only "base64" supported) fields which the RPC API does not.
* The REST API returns "description"; the RPC API also returns it, but is moving to call it "summary"
* The REST API returns "attacher"; the RPC API also returns it but is moving to call it "creator"
* The REST API does not have "creation_date" and "modification_date" for flags.
* The RPC API returns a "last_change_time"; the REST API does not.
* The REST API does not return attachment data by default.


===Create new attachment===
===Create new attachment===
Line 138: Line 188:
* /bug/<id>/attachment POST -- Bug.add_attachment
* /bug/<id>/attachment POST -- Bug.add_attachment


===Retrieve attachment===
Differences:


* /attachment/<id> GET -- Bug.attachments
* The RPC API allows a single uploaded attachment to be added to multiple bugs at once. The REST API does not.
* The above also means the RPC API takes an "ids" array whereas the REST API takes a "bug_id" parameter.
* The REST API allows you to add a comment at the same time; the RPC API does not.
* The REST API uses "description"; RPC uses "summary".
* The REST API allows you to set flags on the attachment; the RPC API does not.


===Search for users===
===Search for users===
Line 266: Line 320:
* Need to check if there are differences in include_fields/exclude_fields support
* Need to check if there are differences in include_fields/exclude_fields support
* What about return values?
* What about return values?
* Compare error handling
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits