14

I have a situation where I need my API to have a call for triggering a service-side event, no information (besides authentication) is needed from the client, and nothing needs to be returned by the server. Since this doesn't fit well into the standard CRUD/Resource interaction, should I take this as an indicator that I'm doing something wrong, or is there a RESTful design pattern to deal with these conditions?

NFicano
  • 1,065
  • 1
  • 11
  • 26

2 Answers2

13

Your client can just:

POST /trigger

To which the server would respond with a 202 Accepted.

That way your request can still contain the appropriate authentication headers, and the API can be extended in the future if you need the client to supply an entity, or need to return a response with information about how to query the event status.

There's nothing "non-RESTful" about what you're trying to do here; REST principles don't have to correlate to CRUD operations on resources.

The spec for 202 says:

The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

You aren't obliged to send anything in the response, given the "SHOULD" in the definition.

Rob Hruska
  • 118,520
  • 32
  • 167
  • 192
0

REST defines the nature of the communication between the client and server. In this case, I think the issues is there is no information to transfer.

Is there any reason the client needs to initiate this at all? I'd say your server-side event should be entirely self-contained within the server. Perhaps kick it off periodically with a cron call?

Paul Degnan
  • 1,972
  • 1
  • 12
  • 28
  • 2
    No information to transfer doesn't mean client can not initiate a call. Think about a "reboot" trigger to a virtual machine resource on server side. Things like that. – RayLuo Jul 24 '13 at 15:17