Re: Web service question...

But I'm sure we are actually agreeing and I just can't see it over this

Hi John,

<snip>
1.
A web service is any service accessed using the HTTP protocol, hence "web"
in the name.
</snip>

This is not true. There are many web services that communicate using
transfer protocols other than HTTP. If I was pedantic I suggest HTTPS, but
I'd never do that. :-)

I agree that generally HTTP is the dominant protocol used. But Microsoft
specifically developed WSE 3.0 to make protocol independent web service
calls easy in .NET - back in 2005.

<snip>
3.
REST (representational state transfer) is an architecture to access and
manipulate "resources", were each resource can have specific
"representations" when transferred to a client (browser). For example i can
have a resource named "clients" and i can retrieve a list of customers with
URL ".../customers". The list of customers is transferred to the client
(browser) in XML format and this is a "representation" of this resource
(could be anything). I can also access the customer with number 1234 with
".../customer/1234 and i get a representation of this customer. To update a
customer with a new name, i POST to URL ".../customer/1234/update" with the
new name (e.g. in XML format) as the payload. In REST style, the HTTP (Web)
protocol is followed. Eg. the browser may use HTTP header "Accept:" to
indicate which "representations" (content-types) it accepts, and the
server's response includes HTTP header "Content-Type" to indicate which
representation is used. Also, the POST returns the location URL of the new
(or updated) resource. Also the "list of customers" should include the URL
locations of each "customer" resource, such that a browser could navigate
through all resource from one entry point (such as the list with customers,
then to a customer, then to it's orders, etc). Much like the Web works with
hyperlinks.
http://en.wikipedia.org/wiki/Representational_State_Transfer
</snip>

Here you state that: "In REST style, the HTTP (Web) protocol is followed."
This also isn't true. HTTP is RESTful. REST is not HTTPful. There is a
significant distinction between a protocol that conforms to an architecture
and an architecture that conforms to a protocol (if that is even possible).

REST is a concept - it is the idea that the client has a picture (or
representation) of a "thing" in a certain well defined and valid "state".
The "thing" exists on the remote server. Changes to the state of the "thing"
from one valid state to another valid state is performed via a call to a web
service. A RESTful architecture will provide a set of services that allow
the client to describe the current state (customer details, order details,
invoice details) and to also change the current state (start order, add
item, pay bill).

A browser using HTTP to communicate with web servers does this admirably
because the protocol is RESTful in its design, not because it is HTTP.

Constrained Application Protocol is designed to be RESTful but it does not
run over HTTP.


But I'm sure we are actually agreeing and I just can't see it over this
nice glass of red I'm drinking. :-)
Cheers

Larry Ducie

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.