CODEWITHSUNDEEP
web-servicesrest
Philipp Murry
Philipp Murry

Reputation: 1682

ReST philosophy - how to handle services and side effects

I've been diving into ReST lately, and a few things still bug me:

1) Since there are only resources and no services to call, how can I provide operations to the client that only do stuff and don't change any data? For example, in my application it is possible to trigger a service that connects to a remote server and executes a shell scripts. I don't know how this scenario would apply to a resource?

2) Another thing I'm not sure about is side effects: Let's say I have a resource that can be in certain states. When transitioning into another state, a lot of things might happen (e-mails might be sent). The transition is triggered by the client. Should I handle this transition merely by letting the resource be updated via PUT? This feels a bit odd.

Is this how it's supposed to be?

BR, Philipp

Upvotes: 1

Views: 120

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57279

Since there are only resources and no services to call, how can I provide operations to the client that only do stuff and don't change any data?

HTTP is a document transport application. Send documents (ie: messages) that trigger the behaviors that you want.

In other words, you can think about the message you are sending as a description of a task, or as an entry being added to a task queue. "I'm creating a task resource that describes some work I want done."

Jim Webber covers this pretty well.

Another thing I'm not sure about is side effects: Let's say I have a resource that can be in certain states. When transitioning into another state, a lot of things might happen (e-mails might be sent). The transition is triggered by the client. Should I handle this transition merely by letting the resource be updated via PUT?

Maybe, but that's not your only choice -- you could handle the transition by having the client put some other resource (ie, a message describing the change to be made). That affords having a number of messages (commands) that describe very specific modifications to the domain entity.

In other words, you can work around PUT =/= PUT by putting more specific things.

(In HTTP, the semantics of PUT are effectively create or replace. Which is great for dumb documents, or CRUD, but need a bit of design help when applied to an entity with its own agency.)

And implementation wise, I have to check what exacty the PUT request changed, and according to that trigger the side effects.

Is this how it's supposed to be?

Sort of. Review Udi Dahan's talk on reliable messaging; it's not REST specific, but it may help clarify the separation of responsibilities here.

Upvotes: 2

Related Questions