Available Affordances?

[ambsw-technology]

A true RESTful interface (i.e. following HATEOAS) can often (always?) be efficiently modeled as a state machine. To do so, the links/actions section is populated based on the available state transitions (i.e. affordances).

There's a certain symmetry between real life and an FSM with a hidden state, but it makes the calculation of affordances especially difficult. Is the package specialized for a different use case (e.g. embedded programming)? or does a method listing affordances make sense?

[glyph]

The problem here is the method would need to have a huge list of sophisticated interactions with the type system, because inputs can take parameters and return values. How to properly express which methods are callable? How to express them if some are private, but re-exposed through a public interface that produces multiple inputs? This might be a good idea but it would need to be very carefully thought through.

[glyph]

Closing this because it's somewhat unclear how to make progress on this as a feature. Please feel free to open a new issue with a more precise description.