From: Dmitriy S. <sha...@gm...> - 2009-11-28 04:01:33
|
On Fri, 2009-11-27 at 13:33 +0000, Thomas White wrote: > 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} For me (as linguist :) no differences between "object" & "module". To make it flexible: /admin/{object}/{object}/{action}/{object}/{object} The parsing is quite simple: 1. analyze first "object"s till get the module. (possible to omit) 2. "action" = function 3. second "object" - the information for function That is very simple, the "action" split "object"s on "which" & "where". The parsing time should be low too. > 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} /admin/administration is tautology. we did definition area by "admin", why redefine it again by administration. It can be /siteN/admin/.... Your idea is based on different users usage, but "server" for system admin, "server/backup" backup admin. My view: /admin/system/restart /admin/system/reload /admin/system/shutdown /admin/backup/{root-collection-of-the-backup}[?to=c:/backups] /admin/restore/{root-collection-of-the-backup}?from=c:/backups/backup-file.zip /admin/reindex/{collection-URI} "system" -> module; "restart" -> function "backup" -> module & function If be honest, I like single "module & function" concept more that "module & functions". It's simple in developing & understanding. > 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. {action}/{object}/{object} should be ok here. /admin/log/period/eXist.log/{datetime}/{datetime} /admin/log/tail/{log-id} (funny, it can be /admin/eXist.log/period/{datetime}/{datetime} & it possible to parse & "understand"! "log" miss, because of "eXist.log" - it have single "meaning") -- Cheers, Dmitriy Shabanov PS I what to try coding, any svn? under eXist one? |