Hi Simon, Thanks for your reply, sorry to take a while to get back to it.
On 20/01/11 08:21, osimons wrote: > On Jan 13, 6:33 pm, "Piper, Nick" <[email protected]> wrote: >> Trac developers, >> >> We're considering implementing an IRPCProtocol (http://trac- >> hacks.org/wiki/XmlRpcPlugin) to provide a REST-style API >> (http://en.wikipedia.org/wiki/Representational_State_Transfer). [..] > I'm somewhat confused about needs here. > > 1) The RPC plugin also supports JSON-RPC by default. That means you > can post a body looking like this: > > {"method": "wiki.getPage", "params": ["WikiStart"]} > > ... and get a JSON formatted response back. See here for docs on an up- > to-date installation: > > https://www.coderesort.com/p/open/rpc#JSON-RPC We've tried this out, and it works fine. Most of our usage has been over XML-RPC so far though, just because of the nice client library in default Python. > > 2) If you don't intend for REST to be ~JSON, but somehow more "plain" > or different then have you considered the actual format for requests > and responses? A pure "REST" response does not make sense as implies > nothing about how you call methods and what you can expect from > responses when you need to parse the output. XML-RPC and JSON-RPC are > stateless calls with either XML or JSON formattet POST body, and parse > either XML or JSON formatted results according to specifications. The > format and usage details are much more complicated than adapting from > POST to a combination of GET, POST, PUT and DELETE requests. However, > if you want to go for a "pure REST" then your protocol a) needs to > define how url is mapped to method invocations for default methods and > plugins adding new unknown methods, and of course b) define response > for parsing. The main difference from JSON-RPC to what we had in mind, is that instead of POSTing to a fixed URL, there would be GET, POST, PUT and DELETE requests to different URLs depending on the resource being manipulated. I agree we'd have to deal with (a) and (b). > 3) XML-RPC may look "complicated" but all major languages and > platforms have decent libraries available. The XML spec has a major > advantage in that it provides additional types such as datetime and > binary, allowing you to directly convert something like "1234567" into > a meaningful result. For JSON I needed to work around this by adding > some custom structures, but the XML format is really a better choice. > As you can see from the same docs, the XML format is really simple > too: > > https://www.coderesort.com/p/open/rpc#XML-RPC We have two main drivers: * Can we be compatible with our existing REST/JSON API in our older product. This isn't a long term consideration, but if it was easy to do, we'd do it. I realise we've not shown you the API (except a minor example below), so not asking for advice on this point. * Make it easy/acceptable for "enterprise" products to interact with Trac. To this end we'd prefer to have something that our Microsoft-platform developers have heard of and experience of. We've been talking internally and finding that actually our current REST/JSON API isn't that easy to use from (say) SharePoint anyway, so it might be that moving to XML-RPC is equally difficult, or maybe even easier. One of our SharePoint developers is investigating. We're hoping that we find the XML-RPC API is already very easy to use from .net, in which case we will probably just stop here. > This was not at all intended to argue for you to use what we already > have, but more a response asking you to think through how you actually > want requests and responses to look like. Such usage example makes it > much easier to discuss details of implementation. Here's just one example (but if we ported this, we might use /tickets instead of /issues): Update Issue ------------ **PUT /issues/<id>** - Update issue with issue_id ``<id>``. A simple way to perform an update is to simply retrieve an issue (`Show Issue`_), update the fields you want to change and PUT it back to the server. Fields that shouldn't be updated may be omitted. The type of an existing issue cannot be changed. The extra field ``comment`` may be included, and will show up in the issue's log. **Parameters:** Issue fields. **Body:** JSON. **Response codes:** ``400``, ``200`` **Response headers:** None. **Sample request:** ``PUT /issues/3?component=Another+Component`` - Set the component of issue to "Another Component". The same request as a JSON body: ``PUT /issues/3`` .. code-block:: text {"component": {"href": "https://example.net/api/2.0/Product/components/Another+Component"} } -- [email protected] | www.logica.com Logica UK Limited, registered in England & Wales (registered number 947968) Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United Kingdom Sorry for this disclaimer: -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
