Patzer, Andrew (2007). Integrating Business Partners the Restful Way.
Chapter 27 (pp. 451-462) in Oram & Wilson (eds),
Beautiful Code. Sebastapol, CA: O'Reilly.
When building the response to the XML query, why is it better to assemble it piecemeal, instead of using a dedicated XML library? XML has a couple quirks (encoding requirements for angle brackets, etc) and it would seem to me that it would be easier to let someone else handle that.
In Chapter 27 of "Beautiful Code", Patzer writes that he's "not a big fan of making technical decisions based solely on whatever happens to be in style at the moment" (451). On the surface, this seems like a reasonable statement - popularity doesn't necessarily mean that something is well-executed - but is popularity of a particular tool or program in fact a good reason to use it? Patzer's example, a company that wanted to make sure their order management and inventory systems communicated and worked efficiently with their distributor's systems, doesn't prove or disprove his earlier assertion; he makes it clear that he believed this to be a reasonable request. Outside of this example, though, the chapter raises some interesting questions - how hard should we as programmers work to make sure that other programmers, with varying levels of knowledge, will be able to successfully modify our programs? Should we use tools and programs because they are widespread?
Could you please explain how XPath parses Rosettanet standard XML
documents? What are nodes in an XML document?
Patzer discussed using the Rosettanet E-business protocol, an XML
standard for implementing interfaces and interactions between companies.
I couldn't quite figure out from the code how this standard influenced
his code and design decisions, and on that note, what other standards
are commonly followed in software design and how do they influence code
in general?
What are some of the differences/similarities between the SOAP and REST approaches to web service design that the author describes? SOAP, apparently, is more appropriate for use in an environment where users are expected to have little or no programming ability, or where anonymous use is involved. Other characteristics are unclear to me.
My question deals with the choice of using REST over SOAP. From what I gather, the choice sounded like it was made from lack of necessity, indicating that REST was simpler to implement. How much easier is REST to implement than SOAP, and are there any other reasons for using it besides simplicity, such as being faster or more secure?
It sounds like this code is supposed to be beautiful because it is so
trivial to extend and expand. However, the XML response, which is the
most important part, is an ugly hack job with StringBuffers. If the
response ever changes, some poor slob is going to have to rewrite this
and probably mess it up. Why did Patzer get sloppy?
On page 454, the author explains that a servlet handles only POST requests, by overriding the doPost method of the Servlet interface: what exactly does the author mean by this? Why is it necessary to override the doPost method?
In the reading, as it talks of brevity, the author makes the comment that "never be too innovative" is a key to creating beautiful code. However, he has to be trying to get at something else, because how do programmers get anywhere else if they don't innovate?
Why does the author ignore the libraries that exist to write XML files? His code seems to do a good job following convention, but at the end he abandons it. Is his method actually simpler? The code he uses looks crude. If this is actually the best way to do it, why aren't the XML libraries modified to make them more usable?
On page 458, Patzer states that he likes jumping into coding as soon as possible to accelerate his learning curve. At what point does it make sense to favor experimenting with code over researching more options for implementation?
How are the XPath mappings used to quickly navigate the Rosaettanet?
What would be an example of a SOAP style, and how much extra work would it really require?
;
