> I'd be interested to see whatever we have. Nothing comes up when I > google the old esme-dev google group, but maybe someone has something > somewhere. I checked the old REST API documentation page and didn't > see anything. Do you think I would be able to figure it out from > looking at the source code?
Source code is how I figured it out :) and the description's probably on an even older mailing list ;-) Currently I see only a mapping of current API to a recommended REST API in the wiki, is this the best place I should document it? > That guy may have been me. I'm slowly having it explained to me that > the design principles of ESME don't necessarily match up to the design > principles of HTTP and to a certain extent REST. You'll have to bear > with me as I work through the cognitive dissonance of an HTTP > (document-focused) API to a stream-focused tool. :-) It definitely wasn't you :) I was starting to recognize the principles of pure REST at about that time myself, so you probably know more than me already. > I think what is most helpful is that exceptions have justifications > that are documented unemotionally somewhere accessible. I had not > understood the idea of ESME as stream-based until today due to this > conversation with you and another offline conversation with David. I > now realize that I had seen these very same justifications written > about multiple times before, but never in a way I personally could > understand. Hopefully on my next flight I'll be able to write a blog > and/or wiki page on the topic that may help out others with this > problem in the future. As a rule of thumb, we shouldn't convert the long poll calls into REST-compliant methods. > Thanks for taking the time to work with me on this! You're welcome! As a result of this there's a chance that even I start understanding this REST stuff :) Vassil
