<html><head><style type="text/css"></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV>Hi,</DIV> <DIV> </DIV> <DIV>I'm working with a client on exposing their services to "consumers". They're a large telco and they have lots of folks that want to call into their backend system interfaces. A large group of folks who are clamoring for access to the IT systems are presentation oriented consumers - talented web developers that want to create accounts, display order status and various other things. They don't grok XML well but can work miracles with javascript, css, and dom manipulation. </DIV> <DIV> </DIV> <DIV>For these customers, I've proposed:</DIV> <DIV> </DIV> <DIV>1) No complex request protocol, use what they know, go with puts, gets qstrings and form variables. Do the REST thing.</DIV> <DIV>2) HTML payloads. Since the target is presentation oriented why rotate to data then back to presentation especially when the consumer is better at working with html?</DIV> <DIV> </DIV> <DIV>Now I"m trying to make it work.</DIV> <DIV> </DIV> <DIV>A lot of what these guys do is contact and scheduling oriented so I have proposed and prototyped moving hCard and hCalendar data around for a number of services as our data contract with the consumer. The approach is looking promising.</DIV> <DIV> </DIV> <DIV>I'm now getting into the nitty grit (error handline, state management) and was wondering if anyone else has been down this path already and if they're willing to share insights.</DIV> <DIV> </DIV> <DIV>I'm new to the list and haven't read the full archive yet, so my appologies if this has been hashed out.</DIV> <DIV> </DIV> <DIV>Cheers,</DIV> <DIV> </DIV> <DIV>Jim Culbert</DIV> <DIV>Principal</DIV> <DIV>Culbert Information Associates</DIV> <DIV><A href="http://www.culbert.net">www.culbert.net</A></DIV></div></body></html>