RE: potentialAction for Classes?

On Wed May 21 2014 at 12:18:13 PM, Markus Lanthaler <> wrote:

> On Wednesday, May 21, 2014 11:06 AM, Jason Douglas wrote:
> > You can do that.  The movie review site example toward the end of the
> > announcement spec is an example:
> >
> >
> IMHO this is different. It defines an "endpoint" which is able to process
> ReviewActions. This is not the same as allowing bugs to be marked as being
> resolved by modifying their state.
> > The challenge is that not all bugs are resolvable.  Only bugs from the
> > same database that exist and are open.  That's why it's generally
> > simpler to state on the bug itself what actions it supports.  For
> > example, when I resolve the bug, you can return that it's no longer
> > resolvable but is no re-openable.
> True.. but introducing a (proprietary) subclass like ResolvableBug and
> associating the action to that class is very cheap.
> > One way to strike a better balance is to only refer to the action
> > specifics (including its EntryPoint, etc.) by reference on the bug
> > instances.  Then you're only saying the supported actions and not
> > repeating the action metadata.  You're limiting to processors that can
> > fully dereference objects and re-compose the graph LOD-style, though.
> > Some are limited to one page at a time.
> Yeah, that's also a quite elegant solution but unfortunately it doesn't
> really work with the current design as the EntryPoint is associated to the
> action and not vice-versa.

Why does that matter?  (and you can use the reverse)

> When you implement a RESTful Web API you want to modify the bug by
> POSTing/PUTing to its URL and not to the URL of some other resource
> (EntryPoint).

The design of is not prescriptive about whether
EntryPoints are RESTful are not.  You can re-use the resource URL if it
is... or have a generic service urlTemplate if it's not.


> --
> Markus Lanthaler
> @markuslanthaler
> > On Tue May 20 2014 at 10:58:35 PM, Holger Knublauch wrote:
> > Has there been any discussion around whether it would make sense to
> > allow potential actions for all instances of a class, so that modelers
> > don't need to repeat the same details over and over again? An example
> > use case would be a page listing bugs in a bug tracker. Each bug would
> > have an action to mark it as "resolved". If I understand the current
> > design, the web page would need to include individual Action entries for
> > each bug item, even if they differ with just a single ID. I believe it
> > would be great if this information could be captured once, e.g. via a
> > property "potentialInstanceAction" attached to the type of those bug
> > items, where the urlTemplate is parameterized with a field from the
> > instances.
> >
> > Cheers,
> > Holger
> >

Received on Wednesday, 21 May 2014 19:26:38 UTC