Skip to content

Expressing a Resource's Available State Transitions

James edited this page Aug 4, 2014 · 10 revisions

Convener

James Pozenel (@lectrotext)

Attendees

Kevin Swiber (@kevinswiber), Steve Klabnik (@steveklabnik), Dave Goldberg (@davidgoldberg), Jim Nardecchia, (many more)

Purpose

Round table on how we are expressing available state transitions for resources.

Notes

  • Expressing state transitions in order to avoid turning a service into a series of Remote Procedure Calls (RPC).

  • POST is a good option as a catch-all for any generic operation (i.e.- POST {"action":"lift"}).

  • Add available state transitions as part of a resource AKA Forms. This is an increasingly popular way to serve actions to the client and doesn't require additional service requests to discover actions that can be taken.

  • Using a state machine resource. Sending requests to a state engine that can reply as to the state of the resource in question. Requires additional requests to find state. Off loads the available states data payload to another resource.

  • Steve Klabnik shared the concept of "Verb Exercises" to explore all the state transitions for a resource. During architecture phase describe all the functions of a resource as a paragraph. Underline the verbs and these verbs become a guide to explaining all the state transitions available.

  • Ultimately, careful resource modeling can mitigate many issues with expressing actions that are available. The resource model can infer state by using descriptive elements. Whether this strategy is "discoverable" when talking about Machine to Machine (M2M) communication is another matter.

  • Resources can be bound by context. For example, a pizza can have varied contexts (creation, cooking, consuming, etc). Resource context can completely change the kinds of actions available for that resource.

Summary

No one has yet figured out the best way to make state transitions discoverable. Everyone is encouraged to keep experimenting with hypermedia API's. The more examples produced, the better we, as a community, can refine best practices for expressing resource state in a discoverable API.

Clone this wiki locally