Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
No edit summary |
No edit summary |
||
| Line 69: | Line 69: | ||
==Matching Calls: Details== | ==Matching Calls: Details== | ||
===Search for bugs=== | |||
* /bug GET -- Bug.search | |||
Differences: | |||
* The REST API gives you the full power of the HTML query interface. The RPC API is a simple ANDed exact match search, covering only a limited number of fields. This is the major difference. | |||
The following differences are copied from the analysis of the call for returning a single bug. | |||
* 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. | |||
===Create new bug=== | ===Create new bug=== | ||
| Line 88: | Line 106: | ||
Differences: | Differences: | ||
* The REST API does not support the experimental "permissive" boolean on requests | * The REST API returns only a single bug; the RPC API can return multiple bugs. | ||
* The REST API does not support the experimental "permissive" boolean on requests. | |||
* The time tracking fields are defined as double in RPC, and Decimal in REST. | * 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 returns User objects instead of email addresses. | ||
| Line 153: | Line 172: | ||
* RPC "who" field is "changer" in BzAPI | * RPC "who" field is "changer" in BzAPI | ||
* RPC "when" field is "change_time" in BzAPI | * RPC "when" field is "change_time" in BzAPI | ||
* The BzAPI call uses consistent, modern field names for the 'field_name' field on each history entry | * The BzAPI call uses consistent, modern field names for the 'field_name' field on each history entry. I'm not sure what the RPC API does, but it may well use the traditional field names (e.g. "bug_status"). | ||
* The BzAPI call returns User objects rather than email addresses for the 'changer' field | * The BzAPI call returns User objects rather than email addresses for the 'changer' field | ||
| Line 315: | Line 334: | ||
(although some config stuff is available as more specific calls) | (although some config stuff is available as more specific calls) | ||
==Meta Issues== | |||
Reviewing the "Matching Calls" section, it seems that the following issues come up more than once: | |||
===User vs email=== | |||
REST uses User objects whereas RPC uses flat email addresses. The question here is whether the display name (and perhaps other info) about the user is sufficiently useful on a regular basis to be made part of the returned data. If it is, that would suggest moving to what REST does. If not, that would suggest moving towards what RPC does. | |||
This is also an issue for Group objects vs. group names in the bug retrieval API. | |||
===Multiple values for a field=== | |||
The RPC API has an add/remove/set model for updating fields with multiple values, such as "blocks", "depends_on", "cc", "groups", "keywords" and "see_also". The REST API has only a "set" model. This is an API design difference. | |||
===Config information=== | |||
The REST API returns one single large config info JSON structure. The RPC API has a more fine-grained approach, and does not provide as much information even if you add it up from all the possible calls. This is an API design difference. | |||
===Error handling=== | |||
The REST API returns various different flavours of error depending on the underlying implementation, whereas the RPC API simply returns an error code and description. | |||
==Scratchpad== | ==Scratchpad== | ||
* Need to check if there are differences in include_fields/exclude_fields | * Need to check if there are differences in include_fields/exclude_fields handling -- see {{bug|540818}} | ||