Re: Web service question...

[Rory Hewitt <rory.hewitt@xxxxxxxxx>]

Henrik (& Bryce),

No, it does not - at least not unless you have sufficient authority to do
so, of course - just like everything else.

If you want to learn more about DB2WSE, I suggest you read the manual - it's
pretty easy to understand.

Don't tell me about a browser being a loose gun - we've had disagreements
before about internet security...

Rory

On Wed, Jul 20, 2011 at 11:29 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

> Does it also allows
>
> <STATEMENT>
>  update petstore/item set itemId = ''
> </STATEMENT>
>
> nice REST service ;-)
>
> A browser is a loose gun, remember that !
>
> On Wed, Jul 20, 2011 at 8:17 PM, Rory Hewitt <rory.hewitt@xxxxxxxxx>
> wrote:
>
> > All,
> >
> > FWIW, without wanting to disagree about what REST is (or isn't), much
> > discussion of REST on the web points to its relative simplicity and
> > implementation. Many of these examples show how a possibly complex
> > procedure
> > call can be simplified to a simple URL.
> >
> > I suspect that in many cases, this is what people 'mean' when they talk
> > about a RESTful implementation or interface - the fact that you can model
> > your application (a collection of web services) in such a way that each
> is
> > a
> > stand-alone object which can be called using only a URL to perform a
> > specific action. This 2003 article points out that 85% of developers who
> > interface to Amazon's web services do so using REST rather than SOAP. Old
> > article, of course, but stil...
> >
> > This is not to say that this is what REST *is* - but I have to admit that
> > when I first looked it up on Wikipedia several years ago, I was pretty
> > baffled. On looking at that Wikipedia entry again, I think the total lack
> > of
> > good examples is a severe deficiency.
> >
> > Rory
> >
> > p.s. KrengelTech (home of Aaron Bartell) has a pretty nifty product
> called
> > DB2WSE (http://iwiki.krengeltech.com/wiki/DB2WSE_User_Guide) which
> allows
> > you to run SQL queries against your back-end database using either a
> > 'complex' XML interface or a much simpler REST (or at least REST-like)
> > interface, e.g.:
> >
> >
> > http://red.rpg-xml.com/db2wse/demo:demo/petstore/item/est-1
> >
> > instead of
> >
> > <DB2WSEREQ>
> >  <STATEMENT>
> >    select * from petstore/item where itemid = 'EST-1'
> >  </STATEMENT>
> >  <USER>DEMO</USER>
> >  <PASSWORD>DEMO</PASSWORD></DB2WSEREQ>
> >
> > It is this user-visible feature of REST (the simple interface) which is
> > what
> > many people 'mean' when they talk about the benefits of REST.
> >
> > On Wed, Jul 20, 2011 at 9:25 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:
> >
> > > I agree with that, REST has a very loose definition and I will go
> further
> > > than
> > > that and argue that most REST services when evoked from AJAX in a
> browser
> > > uses POST in order to ensure that the client don't get buffered data.
> > >
> > > You can argue that REST acts like and is a RPC (Remote Procedure Call)
> > >
> > > As an example a CGI program that acts as a CRUD service and where the
> > > program just remains active and stateless under the Apache environment.
> > >
> > > Further more XML isn't the only way to communicate because the
> interface
> > > is bilatteral agreed so a REST service could also communicate in JSON,
> > > consume FORMDATA etc.
> > >
> > > Most of these definitions discussed here overlaps each other in one or
> > > several ways.
> > >
> > >
> > > On Wed, Jul 20, 2011 at 5:48 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx
> > > > wrote:
> > >
> > > > That's a reasonable description, but of course the devil is in the
> > > > details.  First, a lot of RESTful services don't rely on the HTTP
> verb.
> > > > They all use GET (some use POST) and then leave it up to the service
> to
> > > > determine what to do.  This is often the case when you simply expose
> > > > business logic as RESTful services; the HTTP interface is always the
> > > > same, the service interprets and executes the request.  That makes it
> a
> > > > little easier to program the JavaScript on the browser; it doesn't
> have
> > > > to worry about different verbs.  Second, XML is no longer the only or
> > in
> > > > some cases even the dominant format for the message.  JSON is used
> more
> > > > and more for both sides of the transaction, especially in Rich UI
> > > > applications where both the client and server are written by the same
> > > > development organization.
> > > >
> > > > Joe
> > > >
> > > > > The way I've always described it...
> > > > >
> > > > > 1) In REST, the URI describes a "thing" to be acted upon.  (Ex: An
> > > > > invoice, PO, zip code, whatever)
> > > > >
> > > > > 2) In REST, the HTTP method is the "verb" telling it what to do.
> > > > > (Retrieve, Update, Delete, Insert, etc)
> > > > >
> > > > > 3) In SOAP, the URI describes an 'endpoint' which generally refers
> to
> > > > > some piece of software rather than a thing to act upon. A second
> URI,
> > > > > called Soap Action describes what that software should do. A set of
> > > > > input parameters defined in an XML message describe what data to
> act
> > > > upon.
> > > > > 4) In both cases, an XML message is returned, either as the output
> of
> > > > > the web service, or describing the effect of calling the web
> service.
> > > > > On 7/20/2011 4:51 AM, Larry Ducie wrote:
> > > > > > 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).
> > > > --
> > > > 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.
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Henrik Rützou
> > >
> > >  http://powerEXT.com <http://powerext.com/>
> > > --
> > > 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.
> >
> >
> > --
> > Rory Hewitt
> >
> > http://www.linkedin.com/in/roryhewitt
> > --
> > 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.
>
>
>
> --
> Regards,
> Henrik Rützou
>
>  http://powerEXT.com <http://powerext.com/>
> --
> 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.