Good question. It's also not easy for me to draw a line between RESTful and RESTless services.
Although TAPIR is based on operations, which could be seen as something closer to an RPC approach, it has just a few quite generic operations. On the other hand, for sure TAPIR offers simple ways to interact with the service and to easily expose URLs for any underlying resource (using the term "resource" here in the general sense). REST junkies can even configure re-write rules very easily on a web server to allow "cleaner" URLs for resources that are exposed through a TAPIR service.
I don't think TAPIR is harder just because you need to follow a specification - this could actually make things easier, obviously depending on the complexity of the specification. Remember that TAPIR was created to be used by distributed data providers who want to share the same kind of data using the same protocol, so there's all that additional stuff related with data abstraction, conceptual schemas, etc. The BCI service seems to be built on top of a central database in a single data provider scenario (or am I wrong?) so it's understandable not to use TAPIR.
I think it was Wouter who found some time ago a generic XSLT to convert any XML to JSON. I never used it and I'm not sure if I still have a copy somewhere. A first step towards standardizing JSON representations for our objects could be to play with this kind of generic stylesheet to convert TDWG ontolgy objects represented in RDF/XML to JSON.
Best Regards, -- Renato
Yes I think you are right a REST section would be good but.... What is REST? In a way the TAPIR specification (especially in its lighter versions) is 'just' a common REST specification. You pass it parameters over HTTP and you get back data as XML. On the other hand TAPIR seems more complex than just putting a REST service together. Perhaps because doing anything that meets a specification rather than just what comes to hand is going to be harder. Perhaps Renato may have comments on this.
I have actually just done a REST/JSON service for BCI.
I am nervous because it is totally not TDWG standards compliant and just a useful thing for getting data back for mashups and embedding. Effectively exposing the database to client side applications. From an engineering point of view it is dead simple - a single PHP file (within the Zend Framework). To write code to consume this is trivial (there is an example) but it is bespoke. a major thing is that the return type is JSON which I think many people think of a standard data format for REST type services.
So it would be a good to get some clarification on what we mean by REST.
Does REST tend to imply a particular return type?
If we mean REST/JSON does anyone have an idea how we could get some data typing in a JSON object so that a consuming application could tell that it is a representation of a DwC object or something from the TDWG ontology? Service description is also an issue. We end up re- inventing TAPIR if we aren't careful.
I am sure it would be trivial to wrap a TAPIR provider in something that converted the XML output to JSON enabling it to act as a data source for client mashups.
As usual I'd be grateful for opinions on this. Perhaps we should talk in Fremantle.
All the best,
Roger