blurb.txt

Approval resource URL is discovered through the base resource, no naughty URL templating.

GET /resource/5/approve

404 when not approved, 200 with the thingy-approval resource once approved.

PUT /resource/5/approve

Replaces the current approval message or whatever (you can always store a history of approval messages internally).

DELETE /resource/5/approve

Undoes the approval.

resource.xml

<thingy>
  <link rel="self" href="/resource/5" content-type="thingy" />
  <link rel="approve" href="/resource/5/approve" content-type="thingy-approval" />
  <status>pending</status>
</thingy>

One question I always have the use of meta-data is how do you know whether you need to PUT or POST, i.e. can result in undesirable repeat behaviour. In the above example you could send an email notifying the owner of the thingy that it's been approved. OR is it the responsibility of the API to support a PUT and POST operations and make the former idempotent?

It doesn't quite work in this scenario I would say but you can remove the link from the base resource when you want to discourage people from executing it. However, that doesn't stop it from happening due to timing issues for example.

As to what methods are possible you can add an addition attribute like "methods" but that's what an OPTIONS request is for really. Again, once you've received the first resource you might no longer publish the fact that the URL will accept a PUT but you still need to account for it happening.

If your domain requires a single approval then I would use POST and then reject subsequent requests. However, it can be useful to use PUT but replacement resources trigger a "approval reason changed" event internally rather than a "resource approved" event so that you can respond differently.