[cosmo-dev] Ticket management API (Was: Generating tickets to
share collections)
Travis Vachon
travis at osafoundation.org
Tue Mar 4 10:12:18 PST 2008
+1 to all this, this definitely sounds like the right plan.
On Mar 4, 2008, at 10:02 AM, Brian Moseley wrote:
> On Tue, Mar 4, 2008 at 9:45 AM, Travis Vachon <travis at osafoundation.org
> > wrote:
>
>> Another possibility would be to add some url space to which we could
>> post Cosmo Atom extension tickets (see details link above). For
>> example, posting '<cosmo:ticket cosmo:type="read-only">ub33mmsss1</
>> cosmo:ticket>' to https://hub.chandlerproject.org/atom/collection/d9a6a8a5-7e46-4e7d-94b9-3f20c818e58c/tickets
>> would create a new read-only ticket on that collection.
>
> if you're going to add complete CRUD capability for tickets to the
> feed service, I suggest modeling a ticket as a separate resource.
> here's a quick proposal:
>
> POST /collection/{uuid}/ticket - adds a ticket for that collection
> GET /collection/{uuid}/ticket/{key} - gets a representation of the
> ticket
> PUT /collection/{uuid}/ticket/{key} - forbidden, as tickets are
> immutable
> DELETE /collection/{uuid}/ticket/{key} - deletes the ticket from the
> collection
>
> using XHTML and a microformat to represent a ticket seems reasonable.
>
> it's also nice to have the cosmo:ticket extension element available in
> the collection details as we currently do. this allows the client to
> see the pertinent details of every ticket for the collection in one
> request. we could add a 'href' attribute to the element specifying the
> url for the ticket's resource. similarly, we could add a link element
> to the details feed with rel 'ticket' that specifies the POSTable URL
> for creating new tickets on the collection.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
More information about the cosmo-dev
mailing list