Home/ Questions/Q 7656953
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T12:54:04+00:00

In my resource model I’ve got a subscription resource. It goes through lifecycle states

  • 0

In my resource model I’ve got a “subscription” resource. It goes through lifecycle states like “unsubscribed” -> “subscription pending” -> “subscribed” -> “unsubscription pending” -> “unsubscribed”.

To allow clients to subscribe or unsubscribe a subscription, I’m planning to expose two controller resources (called “sub” and “unsub”) for subscribing/unsubscribing the subscription, each accepting POST requests which will synchronously put the target subscription resource into the appropriate “pending” state, and asynchronously perform additional work to put the subscription into the “subscribed” or “unsubscribed” state.

I can think of a couple of ways for the client to designate the target subscription when making a POST request to “sub” or “unsub”. I could put the target subscription ID into the URI, like so:

/subscriptions/{subscription_id}/sub
or maybe
/sub/{subscription_id}

[Note: exposing the subscription ID in the URI would not present a security issue for my app.]

Or, I could make the subscription ID a POST param to:

/sub

Thoughts on which approach is preferable? If you prefer the URI approach, which URI style do you like better, and why?

Note: a subscription which has been unsubscribed could subsequently be resubscribed, so the “unsubscribe” action is not equivalent to deletion of the subscription resource.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would make the ID a POST parameter to /subscription .

    Instead of having a separate /unsubscribe resource, I would send a DELETE request to /subscription (passing in the ID in the same way).

    I chose subscription instead of subscriber because there is ambiguity in subscriber as to whether you’re creating/deleting subscriptions or actual subscribers/users.

    EDIT – post-clarification.

    REST uses the verbs GET, POST, PUT, and DELETE. GET here doesn’t make sense for creating/updating. You don’t want DELETE because you want the resource to stay around. So I would recommend doing a POST for creating/starting a subscription and a PUT for modifying/unsubscribing a subscription. It’s a slight misuse of the PUT verb but I think it fits your case a little better than the alternatives.

    • 0