ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
RE: [xml-dev] HTTPEctomy considered bad (was RE: RE: [xml-dev] MS thinks HTTP Needs Replacing???)
by Michael Brennan other posts by this author
Feb 28 2002 11:29PM messages near this date
RE: [xml-dev] Check out the pipeline submission | [xml-dev] Call For Papers: ebXML track at XML Europe 2002
>  From: Paul Prescod [mailto:paul@[...].net]

<snip/> 

>  Eventually you need to figure out what the data, addressing and
>  invocation model of your web service is. You cannot be 
>  "model-agnostic."
>  You must decide. HTTP already gets you far down this path with its URI
>  addressing model and 4 main methods for invocation. "Abstracting" over
>  HTTP by erasing its model is not abstracting at all. 

Yes, but can you have an abstracted model based on REST principles that can
be mapped onto HTTP in straightforward fashion? It seems so to me, though
I'm not an expert. However, as I've been absorbing the REST debate, I've
been going back and looking at the HTTP spec to see what things HTTP offers
that I can use, and I'm finding quite a bit of useful stuff that I just
haven't paid attention to before. Not many IT developers are goint to bother
with this. They'll follow the lead of their tools.

For example, a developer will have to think about how to handle error
conditions in their web service. Will they go to the bother of looking in
the HTTP spec and see what status codes are relevant to various conditions?
If they use a Java class library with an exception hierarchy in front of
their noses, and the framework knows how to map exceptions to the
appropriate 4xx or 5xx status code, they are more likely to write an
application that returns appropriate HTTP status codes. The framework could
offer established patterns for dealing with async vs. synchronous message
handling. It knows to send a HTTP status 202 acknowledgement; the developer
just thinks about what pattern fits the problem but doesn't need to be a
protocol expert.

It seems to me there is value in a protocol agnostic model built on REST
principles, and tools with "smart" bindings that know how to leverage the
protocol to support the model, rather than the "dumb" WSDL approach that
minimizes the protocol and views it as just transport. 

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl> 

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved