Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
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 | ||
* 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 | ||
Differences: | |||
* | * 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 |