E-mail
Attending: Joel Farrell, Chair; Dan Rehak, Carl Singer, Valerie Smothers
Joel began by asking if we had any other candidates for the technical steering committee. Valerie offered to send an e-mail to Peter and ask.
The group then moved to discussion of the draft article knowing when to rest, which is a positioning paper for rest and SOAP Web services. Carl described an article that he sent out addressing some common doubts about the REST technical style. It addresses how REST can be used for 80 to 90% of what you need. http://www.infoq.com/articles/tilkov-rest-doubts
Joel commented that we don't want to end up in the middle of a religious dispute. He commented that the length of the draft was good and the terminology was right.
Dan asked if we needed to say something that we are not being religious about our definition of REST. Joel commented that was a good point. Many of the uses are not strictly adhering to REST as defined by Roy Fielding in his dissertation: we are using it in a general pragmatic sense. Carl agreed that it does make sense to say there are varying degrees of how restful a web service can be; it depends on requirements. Joel commented we should say that REST is formally defined in Fielding's dissertation; we interpret REST as it is generally used for something that broadly follows this approach.
Section 5 - Joel recommended changing the referencing mechanism to be similar to WS guidelines. He offered to send wording suggestions.
Section 6 - Joel recommended changing the example. If you are posting an activity report xml, that is a resource. If you have a list and you are adding a new item, that's a resource. A better example of a Web services operation would be something related to a business process.
Sec 7 - Joel recommended clarifying with language similar to the following: REST web services may use security mechanisms afforded by HTTP, such as Secure Sockets Layer (SSL), but high level security services would have to be implemented on a case by case basis. Dan recommended including similar wording for reliable messaging. REST doesn't offer the additional capabilities offered by the WS-R standard, which has the benefits of a pre-defined approach.
Carl commented that in general the things handled by ws standards are things you have to be concerned with. The implication that digital signatures aren't possible isn't correct - there is more effort required if using REST.
Dan recommended including a general comment that SOAP is complemented by a variety of WS standards with various degrees of implementation support. RESTful solutions do not have equivalent standards. Joel recommended adding that to the first paragraph.
Joel commented that under other complexities, need to add something. These things are generally easier to accomplish with SOAP and WS*.
The overall approach part is generally ok. Joel recommended adding language stating that if a task analysis lead you to one style of Web services, the fact that a couple of individual services do not cleanly fit into that design does not mean that they should be implemented using the other paradigm. The determination should be made on the central thrust of the system; an exception doesn't mean you should deviate from the overall design pattern. Joel asked to send out the revisions for the group's consideration. Then we will be ready to publish. It is not super urgent. We can publish and then update when the other guidelines come out.
Joel will check on whether or not we can extract from an internal IBM document we went over at the face to face meeting in Baltimore.
Tell Peter we can put branching vs linear virtual patients on the agenda whenever he wants it. We'll focus on whatever other issues come up. What should you say about exchanging virtual patient content across profiles? Are we saying there are two specifications? It's not high fidelity interchange if you go across.
In 2 weeks we will look at rest guidelines.