V3 is a complete rewrite of the Dsco APIs from the ground up. What's different from V2 and why the rewrite?
Why the rewrite?
First, Dsco is adopting a new, even more modern architecture for the underpinnings of the Dsco API layer. This new architecture will allow Dsco to continue scaling out as it has been but more easily.
Second, over the last few years Dsco has moved to a more stream-lined architecture behind the scenes based on real-time stream processing. This change will allow the Dsco APIs to take advantage of the stream processing architecture and provide finer-grained APIs to support more specific use cases without sacrificing performance or scalability.
Finally, Dsco is seeking an opportunity to make a non-backward compatible change to correct some things that could be done better in a rewrite and this is that chance.
- Most model objects used in the APIs will be almost identical with a few minor changes
- Each object will document its changes on the object itself in a section named V3 Versus V2 Differences (here's an example)
- Dsco is ensuring a clean separation between inventory data and catalog data for items and catalog data that was on the ItemInventory object have been removed
- Each API that allows a partner to send Dsco data will exist in multiple versions with Dsco implementing the Large Batch Update version of each first
- Large Batch Update
The API will accept up to 2 gigabytes of objects to be updated at the same time but the API may only be called at most 10 times a minute
- Small Batch Update
The API will accept up to five megabytes worth of objects to be updated at the same time but the API may only be called 10 times a second
- Single Object Update
This API will accept only a single object to be updated at a time and may be called 100 times a second
- Large Batch Update
- Each API that accepts objects to be updated may choose to simply accept the data to be updated and choose to process the data asynchronously
- Dsco will publish an API for each model object that may be updated that allows the developer to retrieve a log of all change that was attempted, allowing the developer to see any failures that may have occurred in case any asynchronous updates after the fact failed
- All webhooks that send notice of updates to model objects will now include additional information about what changed from the previous version of the object to the new one
- Webhooks will implement a more sophisticated and lengthy retry mechanism with less stringent requirements on timeouts to make webhooks more resistant to performance variability of the partner's infrastructure