1. 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…. Wed like to be accommodative as we can.

2. 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.

3. What is REST Practically Speaking: Many sizable REST implementations are Hybrids that, for good reason,… Dont adhere to use/role of Get, Put, Post, Del. Dont adhere to the use of HTTP response codes. Dont adhere to the HTTP rules of idempotent actions. Dont support the separation of form and function.

4. 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.