How to architecture, design a RESTful device controller?

we are planning to develop a device controller for a banking machine. This controller would be embedded directly on the machine, the idea is to use an off the shelf ARM board with Linux for this.

We would like to provide the API as a RESTful Web Service. Probably we would have to separate the software on the controller in at least 3 layers: Web Service Interface, Business logic, Device control logic (this might even run on a different HW).

Business logic and device control logic will probably be implemented in C++ for performance reasons.

No where we have some doubts is: What technologies/programming languages to use to implement the RE开发者_StackOverflowSTful Web Service?

A webserver (lighttpd), FastCgi, C++ would probably be the best solution performance-wise and also because of limited resources on an ARM board. But the downside is probably that implementation would be not as easy as with some "modern" languages like Python, Ruby, Java etc. We have a lot of skills in C++ in the company, a little in Java and no skills at all in Python, Ruby.

Does anybody have any experience with this kind of architecture?

How do Python and Ruby perform on such a small system?

Any experiences with RESTful APIs on embedded systems? (there isn't much around about this on the web)

Thanks for the input

---

In the old time first cgi were binaries (mostly in C), so it's not a problem to code some CGI in C/C++.

After making a restful API would influence only the way your script behave, like reading url and VERB would trigger what ever code.

So I advice you to dig you some resources about C/C++ CGI programming and probably some libraries to facilitate access to POST/GET variable and the decoding.

---

I agree with RageZ; it is not hard to write the server side in C. There is an 'old' CGI library by Eugene Eric Kim: http://www.eekim.com/software/cgihtml/index.html

Given its age, it likely does not have a heap of dependencies on other stuff.

With a CGI, it is rather easy to put your script on some path, say /my/service and then dispatch on the PATH_INFO environment variable which will give you whatever is appended to the context path. Thus

/my/service/a/b would yield /a/b

If you need high performance and can afford the foot-print, you could also use Apache and write a module (which is also not particularly hard).

But FastCGI would of course also perform very well.

Jan