Hi,
I am quite new to web application development and I
have just created a web service using Axis2 1.0. I have also created
a client for testing the
service which is RESTful in its configuration.
Both the web service and client work as expected,
without any problems.
The question I have is the following (and I am not
sure if it is an Axis2 issue at all. But don't know where else to
ask!):
Whilst learning about REST style web services, I
have read the article "Building Web Services the REST Way" by Roger L. Costello
(http://www.xfront.com/REST-Web-Services.html).
The article explains how REST style web service resources should be reachable
via a URL as nouns, not verbs. E.g:
getPart is a verb.
And the URL should be a noun as
below:
If I implement a web
service using Axis2, the service implementation class has methods which can be
called from a client. Therefore if I write a service for parts (as above), I
would have a method with the following signature OMElement getPart(OMElement
element); where element would contain a part id tag with the value "00345". This
style of service suggests to me that the resource is reachable as a
verb.
Wanting to make the service accesible using
noun-type URLs only, I have written a
servlet within my webserver which takes noun-type URLs, interprets them, and then calls the right parts service method
call. I.e:
My servlet then includes the OMElement returned by
getPart("00345") into the body of the servlet's HttpServletResponse object which
my client then receives as a response.
Therefore, I am wondering whether my approach
to making resources available via noun-type URLs is correct, or whether this
is possible to achieve without my customized servlet but
solely through using Axis2 only?
Any input/suggestions in this matter would be very
helpful and much appreciated
indeed!
Regards,
D.
Paloschi
The information contained in this E-Mail and any
subsequent
correspondence is private and is intended solely for the
intended
recipient(s). The information in this communication may be
confidential
and/or legally privileged. Nothing in this e-mail is
intended to
conclude a contract on behalf of QinetiQ or make QinetiQ subject
to any
other legally binding commitments, unless the e-mail contains an
express
statement to the contrary or incorporates a formal Purchase
Order.
For those other than the recipient any disclosure,
copying,
distribution, or any action taken or omitted to be taken in reliance
on
such information is prohibited and may be unlawful.
Emails and other electronic communication with
QinetiQ may be monitored
and recorded for business purposes including
security, audit and
archival purposes. Any response to this email
indicates consent to
this.
Telephone calls to QinetiQ may be monitored or
recorded for quality
control, security and other business
purposes.
