Question

Existing XML webservice

• Processes XML-RPC style requests in which an operation element which identifies the method to dispatch to. For example:

  <protocol><operation>810</operation><user>…</user></protocol>

• The number of parameters vary.

• The XML-RPC handler interprets the 810 token to mean two things. If it receives an element <user> as a child element of <protocol>, it CREATEs an account. If it receives the element <userExisting> instead, it will attempt to log in the user.

New JSON REST API design

• I want to keep this to one REST endpoint e.g. /api/foobar
• I can translate a user creation to a PUT /api/foobar/${user}
• A user removal to a DELETE /api/foobar/${user}
• My current design is to do a POST /api/foobar/${user} with a body { “op”:”login” } for logging in and similarly for logout, the body { “op”:”logout” } will be sent.

What do you people think of this? Brickbats and bouquets are welcomed with constructive comments.

Answer 1

Overloaded POST for a RESTful API is a bit of a kludge, if you can avoid it. For the purposes of login, I would prefer to try to maintain statelessness – this would mean requiring the client to pass HTTP authorization on each request (this means passing the correct Authorization header each time). You use one of the usual authentication methods such as Basic on the first request.