One of the many lessons we learned during the years that we have been implementing TenForce is that it is never deployed stand-alone. We need to interface with time registration systems, helpdesks, ERP systems like the beloved SAP; the list is endless. Unlike many public services (like yahoo), we first supported Soap before we support REST.

The reason for this was our custom script feature. This lets our customers interact at the various points in the item’s life cycle. An item is the basic object in TenForce; it typically represents an action, a meeting, an issue, a project,…

Trained TenForce administrators can use the TenForce Visual Studio add-in to interact with the item. The interaction with the core of the TenForce system in these scripts is done versus the documented TenForce API. For performance reasons, these scripts use a soap API. Besides the classic SOAP API, we recently started deploying a REST API. There are many examples of companies that implement and support both API’s (eg. Ebay, Amazon).

What is REST?

If you like to read more about REST, we can refer to the following little introduction on the yahoo developer network: REST stands for Representational State Transfer. Most of the Yahoo! Web Services use "REST-Like" RPC-style operations over HTTP GET or POST requests with parameters URL encoded into the request.

For more information about REST please check out the following:

• The Beauty of REST by Jon Udell
• Second Generation Web Services by Paul Prescod
• Representational State Transfer in the Wikipedia

The beauty of REST

At the basis of REST is that it uses the common commands like GET, PUT, POST. These are exactly the commands the HTML page inside your browser is using to interact with the server application. This makes the API relatively easy to understand and both the calls and the result are readable by a human.

Typically the result is also encoded in JSON, which makes the protocol lightweight and removes the need for many XML markups.

Conclusion

In this way we gracefully avoided the question which API we should build and support. In fact both are available. Typing “REST versus soap” in the Google search box will give you plenty of reading material about both approaches. Articles we found well balanced and very informative can be found here and here.