Dan,
 
Thank you for the feedback.
 
I can see your preference to the REST URL is /admin/{object}/{action}
 
I would still prefer /admin/{module}/{object}/{action}
 
We need to think about admin work as set of activities where different people will have access to different subset of possible actions. It is an exception, usually for small projects where one person is admin and he is responsible for all admin tasks. More common case is when we have more then one administrator. If we group common activities to a module we can easily grant access to this module and these activities.
 
Conversely if we put all actions for an object in one place /admin/{object}/{action}  then it will be much more difficult or complex do define in details who can do what.
 
We are discussing URLs here and the implementation of all actions for an object, say collection, can still be in a single module.
 
I do not really like the idea of receiving the list of possible actions when URL is /admin/collection. To request the list of action is an action and to me it looks like  /admin/{module}/collection/action-list. It can return the subset of the available actions for the context of the module combined with user credentials including groups and roles. This way we can control the access to the every action depending on who is asking
I not sure about the meaning of  "enable/disable collection operation".  Do you mean to allow the user to perform the actions or not? This could be a case only if we think admin vs non-admin users. In real life wе may have Backup Admin, User Admin, System admin and all of them may have different subset of actions. User admin does not need to be able to shutdown the server, change configuration or access the data in any collection.
 
I like your note about replacing 'do' with 'server' . Then we can have:
 
/admin/administration/server/restart
/admin/administration/server/reload
/admin/administration/server/shutdown
/admin/administration/server/backup/{root-collection-of-the backup}[?to=c:/backups]
/admin/administration/server/restore/{root-collection-of-the backup}?from=c:/backups/backup-file.zip
/admin/administration/server/reindex/{collection-URI}
 
I think we need an extra parameter 'mode' that will define what will be returned - XML, JSON, HTML, XForm.
 
About the log files viewer, I will be happy to put our heads together and come up with a simple and quick solution.
 
I just realised - we may be talking about two different sets of URLs. I believe we are discussing an RESTful API to perform admin actions. These URLs are not the URL that a web application will have - neither the main application URL nor the application modules' URLs.
 
The way URLs are constructed within any web application depends on many factors including the technology and even the personal preferences of the author. Application URLs should not be an object of restrictions or any hard rules.
 
Regards,
Thomas

------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
Linked-In:http://www.linkedin.com/in/thomaswhite0007
facebook: http://www.facebook.com/thomas.0007



2009/11/27 Dan McCreary <dan.mccreary@gmail.com>
eXcellent feedback Tomas.

You have a nice holistic view of other areas of administration that I
had not considered for RESTful interfaces.

A few small suggestions.

To be consistent with the /admin/{object}/{action} format, perhaps we
could officially use "server" as a named object.

So the following might be some actions on the database server:

/admin/server/shutdown
/admin/server/restart
/admin/state/status
/admin/state/statistics

etc.

This might be a little more precise then the label "do".

I would also like to keep all the operations on collections in a
single areas so that we can enable/disable collection operation
buttons.  So if you specify:

/admin/collection

The REST interface would return a list of all possible operations on a
collection:

Create New Index, Edit Index, Estimate Index Creation Time, Index
(Reindex) Collection, Update Index, Change Owner, Change Permissions,
Create New Trigger, Edit Trigger, Add Version, Move, Rename,
Collection Size, Synchronize, Edit Access Policy, Upload Files,
Collection Details, Delete Collection, Copy, Backup Collection,
Restore Collection, Create a New Subcollection

Perhaps I should refactor the collection admin database to include a
single object type code list:

The list of possible admin objects might include:

configuration-file
collection
group
index
log-file
policy
resource
server
trigger
user

etc.

I also would like to suggest we talk to Loren about how we might
create a RESTful interface to an existing logfile analyzer like
"Apache Chainsaw".

See http://logging.apache.org/chainsaw

Loren is an expert on logfile viewing and has already spent a great
deal of time thinking about integrating Apache Chainsaw with eXist.

- Dan