rest - HTTP PATCH method. Content in the request body -


i'm developping rest api using symfony2. have reservation system , send email customer when reservation validate admin.

i have reservation ressource, , can validate reservation using url :

patch localhost/:id/validate

i want know if correct put email content request body when validate ressource, using patch method.

if no, should correct way ?

thanks, mehdi.

first, resources , rest.

when patch localhost/:id/validate should read "i updating existing validate". "a validate" nothing, not proper english. validate not resource, action. when have actions (verbs) in url, api rpc, not rest. see my longer answer here.

so, consider really doing. 1 of below:

  • you updating reservation
  • you creating validation on reservation
  • you replacing reservation validated version of reservation.

the first make sense , simplest.
patch /reservations/{id} status=valid
reservation hold email-adddress? use that. otherwise consider sending email along.
patch /reservations/{id} status=valid&email=foo@example.com.
reads "update reservation email , status following values". since patch (and post) may have side-effects, sending out mail fine.

the second neccessary when 1 reservation has many validations. or when rest-clients need track validations separately reservations (e.g. get /reservations/{id}/validations/{id}). in cases makes sense have validation resource.
post /reservations/{id}/validations.
if reservation has no email-address, send along.
post /reservations/{id}/validations email=foo@example.com.
reads "make validation reservation on email foo@example.com". reads "i make new validation on reservation". since post (and patch) may have side-effects, sending out mail fine.

the third case important, because of side-effects. if want present way clients can there no side-effects, comes play.
put /reservations/{id} room=12&date=1970-01-01&status=valid&email=foo@example.com
reads "replace exsiting reservation validation has validated status." since put should never have side-effects, client can replaying (on e.g. network errors, heavy load or whatever) never cause user spammed.


Comments

Popular posts from this blog

android - Get AccessToken using signpost OAuth without opening a browser (Two legged Oauth) -

org.mockito.exceptions.misusing.InvalidUseOfMatchersException: mockito -

google shop client API returns 400 bad request error while adding an item -