1

I am designing a RESTfull system that is used by a web site to submit application forms and then used by an internal tool to authorise or decline thos applications. I have having a debate in my head around how to constuct this and have two options. PUT or POST.

PUT option

Applications are all listed under and application resource that can be filtered by a state code (new, approved, declined) using a query parameter (the states exposed through a different resource). New Applicatons can be posted to this URL which creates them and assigns and ID. You can then access the application with a GET using its ID. To approve, you PUT one of the statecodes to the application URL to update the record.

     GET Service.svc/statecodes
GET POST Service.svc/Applications?statecode={statecode} /{POST DATA}
 GET PUT Service.svc/Applications/{applicationId} statecode={statecode}

POST OPTION

Applications are all listed under and application resource, new Applicatons can be posted to this URL which creates them and assigns and ID. There are different URLs which show filtered views of the applications: pending, approved, declined. To approve an applicationId would be posted to the approved URL and to decline the URL would be posted to the declined url. These last two posts would have the effect or moving an application from the the pending list and into the approved list.

    POST Service.svc/Applications form={POST DATA}
     GET Service.svc/Applications/{applicationId}
     GET Service.svc/Applications/pending
GET POST Service.svc/Applications/approved applicationId={applicationId}
GET POST Service.svc/Applications/declined applicationId={applicationId}

The PUT method seems the most RESTful to me, but exposes behaviour to the outside world and breaks encapsulation. The POST method seems cleaner and more discoverable but i don't like the side effects of the POST to a resource on another resource.

I feel that actually we should be using SOAP for the approve and decline as it is a command/message rather than a query which is really what REST is all about, but i'm stuck on a path from high above unless someone can help me form an argument for SOAP.

So which is the right or best approach?

Dafydd Giddins
  • 2,276
  • 3
  • 24
  • 31

1 Answers1

1

Get/set application state:

GET PUT /application/{id}/state

If it is not public interface then you could just return 403 (or 401 if it possible to get an authorization to get/set the state) if the request is not from an internal tool.

Submit new application and view it:

POST /application/
GET  /application/{id}

You could also expose all applications with a certain state:

GET /application?state={pending|approved|declined}

The same resource may have multiple urls if you'd like e.g., a collection of applications that are in the state pending:

/state/pending/application

and

/application?state=pending

help me form an argument for SOAP.

Fro an example of how the discussion could go, see Should a Netflix or Twitter-style web service use REST or SOAP?.

Community
  • 1
  • 1
jfs
  • 399,953
  • 195
  • 994
  • 1,670
  • So you are saying that the PUT approach is the correct approach? No comment on the SOAP question? – Dafydd Giddins Dec 16 '11 at 14:36
  • @daffers: I'm saying I see no reason *not* to use it: the url of the resource (state) is known and the semantics of the operation (create/replace resource) is standard. But there *could* be reasons to prefer other approaches e.g., if the operation is not idempotent then POST should be used. The same goes for SOAP. I can't talk about SOAP without using swear words but there might be circumstances when it is a better choice e.g., [if you can't encode all your authentication information into each HTTP request](http://stackoverflow.com/a/3285790/4279). – jfs Dec 16 '11 at 15:59
  • Ok thanks, upvote 1 but not going to take that as an answer. It's probably a question that doesn't have a black or white answer. – Dafydd Giddins Dec 19 '11 at 08:58