KJC>> My $.02. KJC>> Preamble: This discussion about SOAP or REST is a diversion, imo. When it comes down to it I would work with either. But I vote for SOAP for now, reasons below. The much more important and difficult discussion should be around the necessary operations and data model and peering ecosystem. But since SOAP/REST is what we've chosen to focus on in this email thread, here goes.... I'm adding in some technical details here in this response, because talking about this decision purely in the abstract does not do it justice. KJC>> From the all important *practical/business* perspective, SOAP is on the very very short list of B-to-B de-facto API standards at this point in time. REST is *probably* not on that list *yet*, imo. But REST is definitely a very nice and elegant set of architectural principles and approach. And some or all of these principles are applicable in general, even if the delivery envelope is SOAP (idempotence of PUT and DELETE, stateless operations, simplicity, brevity, separation of form and function, etc). And the common instantiation of REST that specifies the use of URIs for identity and type and form, TCP for transport, HTTP for envelope and, HTTP GET/POST/PUT/DELETE for operation/action, is a very elegant and Web oriented approach, albeit a somewhat less practical one at this point in time. As a software developer I very very much appreciate REST, but as a business person I like SOAP at this point in time. It's not fun making a trade-off like this, I wish I was still in graduate school. :-). General questions regarding deployed transport protocols: 1. How many folks have SOAP implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out? KJC>> Add me to that list. When specifying a B-to-B application over the internet, it is easy to get agreement on and adoption of SOAP (sort of like when selecting a relational DB for an enterprise application it's easy to get agreement on Oracle). SOAP, and "simple" XML over TCP, are the de-facto standards for these types of apps, based on the various projects I've been exposed to over the past several years. Prior to the past several years, CORBA was very common (I loved CORBA, :-)), prior to that, home grown text delimiting over TCP was very common (that was fine as well). And-on-and-on-and-on. "Technology thrashing" is the term I like, costing companies millions of $ to constantly change, adapt, re-train, etc. But I digress. SOAP is undoubtedly one of *the* (if not *the* 1) de-facto standards for these types of applications at this point in time. 2. How many folks have a REST-like implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out? KJC>> None that I know of. But there may be. And there would be nothing wrong with that from a *technology* perspective. But a *practical* *business* perspective that necessitates adoption is another matter. 3. In general what data model or protocol properties do your organizations ultimately lean towards - SOAP vs. REST? Other? KJC>> SOAP for now, because that is most practical from a business perspective. But REST has very good technical merits, imo. 4. What are the specific applications that SSP are looking for DRINKS to enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?? KJC>> All of the above. Questions to reach WG concensus on: 3. Do you agree that the design team should define the architecture / data model independently from the definition of a potential transport protocol? (as far as possible) KJC>> Most definitely. I am espousing this approach, which has been successfully applied in other IETF RFCs. However, there are practical side affects of this. Most importantly, the data model must be designed to not prevent the specification of multiple envelopes/architectures, particularly those like REST that impose an approach to Identity (URIs with embedded synthetic keys), Action (HTTP's PUT, GET, POST, DELETE), Type (also embedded in the URIs), idempotence, etc. As specific examples, (1) REST APIs are often/usually built on the assumption that a URI can be used as object identity where any subpart of the URI can be an object identifier, http://adgfadvs.com/serviceArea/3987/17039871234), and (2) that the supported operations on any object type are *at most* DELETE, PUT, POST, GET. Meaning, respectively, that object identity cannot be a composite business key, and that the action/operation should not be embedded as a structure or element in the data model. Both of these requirements of REST will have notable side affects on the structure of the data model. 4. Given the goal to define the data model outside its transport, do you prefer the group to A. Define a SOAP based transport protocol and if anyone is interested they can work on a RESTful version? B. The WG try and do both? KJC>> A, at a minimum. As a software developer, I'm interested in B, but as a business person I am not interested in B at this point in time. It's not fun making a trade-off like this, I wish I was still in graduate school. :-). Please provide feedback before July 8th, if possible. Thanks, Richard & Alex _______________________________________________ drinks mailing list drinks at ietf.org https://www.ietf.org/mailman/listinfo/drinks
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.