Hi Andrei,
I had a look at the spec, and I have some thoughts for consideration.
For starting and stopping services, why not make it a service instead of an
update to state? This would hide the internal details of the state value. For
example:
PUT framework/bundle/{bundleid}/start # starts the bundle
PUT framework/bundle/{bundleid}/stop # stops the bundle
For collections of things, I would recommend using an empty segment at the end
of the URI. For example:
GET framework/bundles/ # gets the list of bundles
POST framework/bundles/ # installs a new bundle
For things that accept a "filter", I would move that to the query portion of
the URI. For example:
GET framework/bundles/?{filter} # gets a filtered list of bundles
When installing a new bundle, I'd like the option of sending the bundle content
instead of a URL.
When getting service meta-data, if the service is not resolved, I would like to
see why. Missing configuration, missing required service, etc.
The specs for the JSON that have array content all need a key:
{
bundles: [bundleURI, bundleURI, ..., bundleURI]
}
Security needs to be addressed. I'd like to see some sort of security service
that we can provide implementations for that separate authentication from
authorization much like the way Restlet does it through filters and it's
security base classes.
Bryan
On Oct 29, 2012, at 5:45 PM, Andrei Pozolotin <[email protected]>
wrote:
> Jerome, hello;
>
> FYI: osgi alliance came up with new rest related spec:
>
> RFC 182 - REST Interface for OSGi
> http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2012-10.pdf
>
> do you mind taking a look sharing your opinion?
>
> Thank you,
>
> Andrei
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3024641
