I prefer the granular design as well - and just to reiterate, the Sling concepts for this are resource providers (and resource access security)
Regards Carsten 2014-02-18 9:47 GMT+01:00 Tommaso Teofili <[email protected]>: > Does anyone else have any opinion and / or concerns? It'd be nice if we can > move forward. > > Regards, > Tommaso > > > 2014-02-14 2:29 GMT+01:00 Alexander Klimetschek <[email protected]>: > > > On 13.02.2014, at 13:44, Tommaso Teofili <[email protected]> > > wrote: > > > > > I personally prefer the granular one as it's more resource oriented, > > which > > > makes more sense in my opinion for an HTTP API (be it REST or not) > > > > Regarding REST: It is closer to REST only once you send out links to the > > various options/commands. > > > > If the client needs to build the request itself and has to know URL > > patterns or other headers or payload paths, it misses the hypermedia > > constraint. > > > > So in itself, there is no real difference between granular and flatten in > > the proposal: > > > > POST /system/replication/agent/{agentName}/replicate > > > > and > > > > POST /system/replication/all/replicate > > { > > "agents" : [ "publish1", "publish2" ] > > // .... > > } > > > > However, the granular one has the advantage that you can more easily do > > the linking, for example using standard <form> and hrefs. > > > > Basically, if you can browse it with some simple HTML pages and do > > everything (find all agents, look at agent state, clear queue, import > > package etc.), then this is good. > > > > Just my 2 cents > > Alex > -- Carsten Ziegeler [email protected]
