Ideas for Arc XP

The Draft API provides the ability to update stories outside of Composer, but it does not provide any interoperability with Composer's story lock. Therefore, updating a story using the Draft API will not respect the story lock and will result in the Composer user being prompted to reload the latest revision, losing any unsaved work. This makes the Draft API impossible to use in many production use-cases without unacceptable impacts to workflow.

Composer uses a simple API to check, acquire, and hold the story lock, but this API is only accessible from within Arc tools due to the way it authenticates. It is not a client-facing API supporting access tokens. Partners have gone to great lengths to work around this limitation, such as using automated test frameworks to script GUI interactions with Composer, and these approaches are notoriously brittle in the face of unforeseen behaviors like user surveys.

Therefore, I propose that the Draft API should, at minimum, reveal the lock status of the story in response to requests like GET /draft/v1/story/{id}. This would allow clients to check the lock status before updating the story. To address the potential race condition, perhaps the PUT/POST endpoints could accept a lock_behavior argument allowing the client to specify that the operation should fail with an appropriate error response if the story is locked, conceptually similar to the collision_behavior argument on the PUT circulation endpoint.

These enhancements would empower automated editing systems to play nice with human editors, using stable APIs rather than relying inappropriately on the DOM stability of Composer's Web GUI for production publishing applications.