Jerome,
I agree that there are two audiences, and that we should make both
comfortable, no reason not to. But I don't think we should comingle
the URLs.
As far as 'asadmin' audience, I would like to be able to write
commands consistent with the 'asadmin' syntax, but I don't think the
URL should require "__asadmin", since commands should be generalized
to all modules, not just.
So I would prefer the term (URI part) 'cmd' for our historical
syntax, and 'rest-cmd' for the style expected for conventional REST eg:
http://localhost:4848/cmd/do-it-cmd <==== noun/options syntax eg
"start-server?name=foo"
http://localhost:4848/rest-cmd/... <==== conventional REST syntax
(not familiar to me)
I definitely think our command support MUST be generalized, and
therefore '__asadmin' is inappropriate.
Lloyd
On Feb 1, 2008, at 10:04 AM, Jerome Dochez wrote:
>
> On Feb 1, 2008, at 9:40 AM, Lloyd L Chambers wrote:
>
>> Well, perhaps let's not call it REST then.
>>
>> I think of it as a "command line in a browser". I LIKE the fact
>> that it is very similar to using the 'asadmin' CLI, including
>> identical command names and option names. I think it would be a
>> huge mistake to introduce an entirely new set of names for
>> commands and options.
> yes but I think we can get closer to how REST does things or if we
> have to, provide different ways of issuing commands, relying on a
> filter on the server side to decipher the command name and
> parameters. It is true that today's format is intuitive to
> glassfish users but not to others. the full REST support would be
> the other way around, I see no reason that we have to choose when
> we can be flexible.
>
> Jerome
>
>>
>>
>> Lloyd
>>
>> On Feb 1, 2008, at 5:31 AM, Paul Sandoz wrote:
>>
>>> Jakub Podlesak wrote:
>>>> On Thu, Jan 31, 2008 at 07:25:01PM -0800, Peter Williams wrote:
>>>>> Is there a document detailing the inputs & outputs for V3's
>>>>> REST api?
>>>>>
>>>>> I found the one here: http://wiki.glassfish.java.net/Wiki.jsp?
>>>>> page=V3AdminCommands
>>>> the above described api doesn't look very RESTfully.
>>>> It uses verbs to specify methods in URIs. It is probably fine as
>>>> long as it is not called REST api.
>>>
>>> Agreed. Although from the documentation i don't think it makes
>>> any claims to be :-) Although i would strongly encourage that we
>>> make it a RESTful API.
>>>
>>> From this documentation it is not clear what the actual HTTP
>>> method is used with the URIs, GET or POST? if the former then it
>>> is very unRESTful and breaks the semantics of the HTTP GET method
>>> which should not have unintended side effects (imagine a web
>>> crawler traversing such URIs and unintentionally causing side-
>>> effects, or reloading the URI in a browser, or clicking in such a
>>> URI in a email message).
>>>
>>> IMHO i think it possible to create a nice RESTful API that is
>>> easy to use by both machines and browsers. We could even create
>>> some WADL for it and transform that to some nice documentation [1].
>>>
>>> For example:
>>>
>>> // get the list of applications
>>> // returns a list of URIs for each application
>>> // use query param to limit scope of list
>>> GET http://localhost:8080/__asadmin/applications
>>>
>>> // Deploy new application
>>> POST http://localhost:8080/__asadmin/applications
>>> // use application/x-www-form-urlencoded
>>> // or multipart/form-data
>>>
>>> // GET the state of an application 1
>>> GET http://localhost:8080/__asadmin/applications/1
>>>
>>> // Undeploy the application
>>> DELETE http://localhost:8080/__asadmin/applications/1
>>>
>>> // Redeploy the application
>>> PUT http://localhost:8080/__asadmin/applications/1
>>> // use application/x-www-form-urlencoded
>>> // or multipart/form-data
>>>
>>> // get the list of modules
>>> // returns a list of URIs for each module
>>> GET http://localhost:8080/__asadmin/modules
>>>
>>> // get the list of containers
>>> // returns a list of URIs for each containers
>>> GET http://localhost:8080/__asadmin/containers
>>>
>>> // get the version
>>> GET http://localhost:8080/__asadmin/version
>>>
>>> // get the domain state
>>> GET http://localhost:8080/__asadmin/domain
>>>
>>> // get the domain state
>>> PUT http://localhost:8080/__asadmin/domain
>>> // use application/x-www-form-urlencoded
>>>
>>> // get the high-level state of everything
>>> GET http://localhost:8080/__asadmin
>>>
>>>
>>> If using PUT/DELETE are in issue it is possible to wrap them in
>>> POST use a filter on the server side to set the appropriate HTTP
>>> method.
>>>
>>> Paul.
>>>
>>> [1] http://www.mnot.net/webdesc/
>>>
>>>> ~Jakub
>>>>> which lists the commands, but I'm really looking for the one
>>>>> where if the "User-agent" is set to "hk2-agent", then specially
>>>>> formatted data is returned (e.g. Manifest format for list-
>>>>> applications, etc) and what the data can be expected to be.
>>>>>
>>>>> If no such document, when and where can I expect to find this
>>>>> information? Or do I have to read the source :o
>>>>>
>>>>> -Peter
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>
>>> --
>>> | ? + ? = To question
>>> ----------------\
>>> Paul Sandoz
>>> x38109
>>> +33-4-76188109
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---
>> Lloyd L Chambers
>> lloyd.chambers_at_sun.com
>> Sun Microsystems, Inc
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc