Difference between revisions of "Zaqar/specs/api/v2.0"
< Zaqar
m (→Marconi API v2.0) |
(→Marconi API v2.0: Added note about custom media types) |
||
| Line 9: | Line 9: | ||
* Only provide a message ID for claimed messages? | * Only provide a message ID for claimed messages? | ||
** Con: user may want to have an auditor that uses the feeds api, and the auditor will need to match up message IDs with the ones being claimed by the workers | ** Con: user may want to have an auditor that uses the feeds api, and the auditor will need to match up message IDs with the ones being claimed by the workers | ||
| + | * Allow custom media types? | ||
| + | ** Message attributes move into X-headers | ||
| + | ** Allows for all kinds of binary types | ||
| + | ** Con: if an error occurs, there isn't an obvious media type the client accepts to use in reporting structured error information | ||
| + | ** Con: X-headers are unwieldy if we need structured message attributes (YAGNI?) | ||
Revision as of 03:23, 11 June 2014
Marconi API v2.0
Brainstorming
- Migrate to topic-based semantics.
- Can post a single message to multiple topics in one request
- Can consumers read more than one topic in a single request?
- Delete a claim to delete all it's messages?
- Need to decide if we want to encourage deleting multiple messages at a time, or if that is an anti-pattern
- Only provide a message ID for claimed messages?
- Con: user may want to have an auditor that uses the feeds api, and the auditor will need to match up message IDs with the ones being claimed by the workers
- Allow custom media types?
- Message attributes move into X-headers
- Allows for all kinds of binary types
- Con: if an error occurs, there isn't an obvious media type the client accepts to use in reporting structured error information
- Con: X-headers are unwieldy if we need structured message attributes (YAGNI?)
