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).
>
> We feel this would make it easier for people to integrate with our Trac
> system, as it's a lot simpler than XML-RPC (at least from other
> languages.) We also have some users of a REST API to our existing
> ticketing system, and when we switch to Trac, it would be nice if they
> had to make minimal changes.
>
> From our point of view, things which might encourage us to do this are:
> * We might be able to get close to compatibility with our existing
> ticketing REST API (this is not published.)
> * Easier for new clients to be developed (REST-json is better known
> than XML-RPC?) (We're mainly interested in "enterprise integrations"
> here, but we're not much a fan of SOAP.)
>
> However, we do not want our own implementation to diverge, so if we we'd
> be trying to encourage take up of the REST interface in the wider
> community, otherwise clients would generally end up using XML-RPC
> anyway, for widest compatibility.
>
> We wanted to post just to bring this up; we've not started work yet, but
> may begin something on Trac-Hacks in February depending on response and
> our own developer availability.
>
> I think this was last discussed in
> 2008:http://www.mail-archive.com/[email protected]/msg02179.html
>
Hi Nick,
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
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.
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
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.
:::simon
https://www.coderesort.com
http://trac-hacks.org/wiki/osimons
--
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.
