From the thread including:

http://sourceforge.net/mailarchive/forum.php?thread_name=4EA4A0CC.3030802%40seefeld.name&forum_name=roundup-devel

On 10/22/2011 09:23 PM, John P. Rouillard wrote:
> I seem to remember somebody posting/mentioning a set of patches to
> roundup that implemented a restful interface for roundup some time ago.

In message <4EA36F33.1040303@...> on 22 Oct 2011 Stefan
Seefeld asked:
>I'm not entirely sure what you mean by 'restful'.

See: http://developer.mindtouch.com/REST/REST_for_the_Rest_of_Us

The basic url is a resource/noun
(https://roundup-tracker.org/tracker/status2 for example) and
uses the http(s) functions of:

  GET - retrieve data about the resource
  POST - creating new resources
  PUT - updating a resource
  DELETE - to retire/delete a resource

with the semantic requirements that:

  GET - must never change any data (idempotent).

  POST - can change data every time it's called, if called multiple times
         can generate new resources every time it's called (not
         idempotent).

  PUT - can be called multiple times without changing the end state of
        the system (idempotent)

  DELETE - can be called multiple times without changing end
           state (idempotent).

So a POST to https://roundup-tracker.org/tracker/status with data:

Headers:
  Accept: application/json
  Content-Type: text/json

Body:

  { "description": "Work is paused pending another ticket getting resolved",
    "name": "paused",
    "order": 5.0
  }

Response:

  HTTP/1.1 200 OK

  { "link": "https://roundup-tracker.org/tracker/status5" }

will create a new status. If posted again, it would create
another new status (in theory only since name is required to be
unique it would fail. However consider the case where it was
creating message).

Doing a PUT operation with the same headers/data to
https://roundup-tracker.org/tracker/status4 would change the
defintion of the status with id 4. With a possible response of

{ "status": "ok"}

Repeating the PUT operation 1 or 1000 times would still result in
the same values for https://roundup-tracker.org/tracker/status4
and wouldn't change anything else.

Also a PUT operation to:

  https://roundup-tracker.org/tracker/issue2300/status

Headers:
  Accept: application/json
  Content-Type: text/json

Body:

  { "value": 1 }

Response:

A GET operation on https://roundup-tracker.org/tracker/status
would return:

[ { "id": 1, "link": "https://roundup-tracker.org/tracker/status1" },
  { "id": 2, "link": "https://roundup-tracker.org/tracker/status2" },
  { "id": 3, "link": "https://roundup-tracker.org/tracker/status3" },
  { "id": 4, "link": "https://roundup-tracker.org/tracker/status4" } ]


and a GET on one of the links above would result in something like:

  { "id": 4,
    "description":"User feedback required",
    "name": "pending",
    "order": 4.0 }

Repeating either GET would result in the same data (assuming no
POST/PUT/DELETE operations occured in the interim).

A DELETE operation on https://roundup-tracker.org/tracker/status4
would retire the status, and a re-DELETE would result in no
change.

>I did add support for jquery (specifically, in the 'devel'
>tracker, in the user index templates). I would love to see the
>"batch" processing be improved to use jquery, but haven't
>managed to work on this (yet). Did you think of that?

I know you can do rest calls from jquery (and json would be a
useful input/output format) but AFAIK there isn't support for
anything expect POST/GET.

Hopefully that explains what I mean better.

    	
    Re: [Roundup-devel] Is there a RESTful interface for roundup?
    From: Stefan Seefeld <stefan@se...> - 2011-10-23 23:18

    On 2011-10-23 18:52, John P. Rouillard wrote:

    [...]

    > Hopefully that explains what I mean better.

    It does indeed, thanks !

    Yes, I think it would be great to have something for this in Roundup;
    perhaps modeled after the roundup.xmlrpc module (and integration into
    roundup.cgi.client).

    This would allow for tracker templates to become more dynamic, as well
    as entirely new client-side applications to be written.

        Stefan