This looks good to me Micah, though I don't think this is a significant departure from the direction we've been trying to go for some time. We're still in the process of "fixing" our endpoints to conform to REST norms. One more comment below...
On Fri, Apr 22, 2011 at 8:42 AM, Micah Sutton <[email protected]> wrote: > Suggestions for our REST endpoints: Primarily POST should be used to create > new resources without specifying a new resource id. PUT should used to > update existing resources. Rest endpoints should use a path parameter to > allow specifying the content type of a GET request where applicable. > > For Scheduler the new structure would look like this: > > GET > /recordings/recordings.{format}?param¶m... - Filter events > (including handling conflicts), and get all events if no filters are > provided > /recordings/{id}.{format} > - Return a single event, 404 if event not found > /recordings/{id}/agent.properties - > Return capture agent properties, 404 if event not found > /recordings/calendars/?param¶m - Return > calendar filtered by param, usually will specific agentId > > POST > /recordings/ - create a > new event or group of events, return list of ids and URIs of created events > > PUT > /recordings/{id} - Update an > event, 404'd if doesn't exist > /recordings/bulkactions/ - Update a group of > events > > DELETE > /recordings/{id} - Delete > the event, 404 if not found, 202 on success > /recordings/bulkactions/ - Delete a group of > events > > Series > > GET > /series/series.{format}?param¶m... - Filter series, and Return > all series > /series/{id}.{format} - Specific > series, 404 if not found > /series/{id}/acl.{format} - ACL for > the specified series, 404 if series not found > > POST > /series/ > -Create new series, return series id > /series/{id}/acl -Create a > new ACL for specified series, 404 if not found > > PUT > /series/{id} - Update > series if exists, or 404'd > /series/{id}/acl - Update > series ACL, 404 if not found > > DELETE > /series/{id} - Delete > series, 404 if not found, 202 on success. > > (Does this one make sense?) > /series/{id}/acl - Delete > ACL from specified series, 404'd > > Yes, it makes sense to me. But I don't see much of a difference between this and what's already in trunk (POST /{seriesID: .+}/accesscontrol). Changing to from POST to PUT seems right, and we probably don't even need a POST for ACLs at all, since the PUT will create or update the ACL. I don't think the path "acl" vs. "accesscontrol" matters that much, so feel free to change it if you like. If you are going to make these changes, be careful with the series identifier; it may contain slashes (hence the use of /{seriesID: .+}/ rather than /{seriesID}/). Josh > There are a lot of other endpoints that are much simpler than these, but > should still conform to the GET/POST/PUT/DELETE Verb actions for those verbs > that they implement. > > Micah >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
