The REST Question for SPPP

• REST vs. ???? is an interesting tangent, imo.• But we need to address the tangent.• Can/Should SPPP be “implemented” using REST?• Informal Poll on WG email list indicated that REST is not a requirement. But….• We’d like to be accommodative as we can.

What is REST• Strictly Speaking: Not a standard, not a tool, not a transport,

not an envelope, not an API. Is a nice set of common architectural principles…

• Stateless Operations• Separation of Form and Function• Simplicity• Idempotent Operations

• Commonly Speaking: A nice set of technologies applied in a certain way that meet the target architectural principles…

• HTTP/TCP for Envelope and Transport• URIs for Object Identity.• HTTP Put, Get, Post, Del for Object Actions• Idempotent rules for Object Actions• HTTP Result Codes for responses.• URIs and URI params for queries.

What is REST• Practically Speaking: Many sizable REST

implementations are Hybrids that, for good reason,… • Don’t adhere to use/role of Get, Put, Post,

Del.• Don’t adhere to the use of HTTP response

codes.• Don’t adhere to the HTTP rules of

idempotent actions.• Don’t support the separation of form and

function.

SPPP and REST• SPPP will be/have/use…

• Transport independent (to the extent possible)• Envelope independent (to the extent possible)• Idempotent Actions (to the extent appropriate)• Small/Common set of Response Codes• XML as the message format• Separation of action and object

• Difficulties for a “good” SPPP using REST:• Not sure anyone sees a need for it.• Response codes and messages are imprecise.• Actions cannot be combined for performance and convenience.• Can be difficult to use business keys, rather then synthetic keys.• Too much information must be moved out of the protocol

specification (actions, response codes, messages, input parameters, etc).

• Idempotent actions are not always appropriate.• Purely stateless connections are not always appropriate.

• A Hybrid SPPP REST Implementation Will be Possible.