Spark-web-embd-rest-json

Hi,
This project implement a Http server on Sparkcore itself (Embedded). Once compiled into the Web IDE, the server will be available at http://IP-SPARKCORE (port 80 by default).

RESTFull URL : http://IP-Sparkcore/D0/on|off
Digital JSON URL : http://IP-Sparkcore/json/dig/
Return : {“TS”:20140802091229,“D0”:0,“D1”:0,“D2”:0,“D3”:0,“D4”:0,“D5”:0,“D6”:0,“D7”:1}
Analog JSON URL : http://IP-Sparkcore/json/ana/
Return : {“TS”:20140802091252,“A0”:2127,“A1”:2117,“A2”:2097,“A3”:2098,“A4”:2107,“A5”:2114,“A6”:2083,“A7”:2085}

Github


3 Likes

Cool. How does this compare with setting/receiving these values via the cloud?

Also, just a fyi to encourage reuse, did you know there is already a webserver library for the spark?

@mdma
Yes I know Webduino, but it works much worse than my project web server. My server is a real server with error handling and multi-tasking …
Webduino library is not comparable.
Try my project to see the difference.
Sorry but I prefer my code.

Hehe, you wouldn’t be the first person to prefer their own code! :slight_smile:

I did take a look at the code. The regex parser looked great - that would certainly be useful as a standalone library if you felt inclined to break that out into a separate lib!

The http parser contains a list of all (dozens!) the possible HTTP methods that are handled, so I’m inferring from that you want the http portion to be a general purpose library? Just a fyi in case you’re not aware, at present the code for the webserver is intermixed with your application handler code, which will prevent separating the http part from the application. Of course that’s no biggie, that’s just about refactoring code and putting the webserver part behind an appropriate interface so it’s reusable (as we have in webduino.)

Other than that, I didn’t see how it’s significantly different from webduino. They both build around a TCPServer that handles multiple types of requests and provide error handling. If I’ve missed something please let me know! :slight_smile:

Finally, if I may offer some advice: you’ll hit a memory wall with the current design of the http server where the different request types provided by the client are instances of a class derived from HttpRequest, which includes two 128 byte buffers, so each request type requires 256 bytes of ram. It would be more scaleable if you used the same user-allocated buffer for all requests (as webduino does.) Requests are handled sequentially, so there is never a need for more than one buffer. You might simply be able to make the buffers static.

1 Like

@mdma
Slow down, i dont speak english. I’m french …

Yes it is true that I have reduced the buffers from 256 to 128, because before the deep update (1.23) CC3000 server could freeze. But I can now increase the buffers, because the problem is resolved.

For Webduino, if I compare, I have a big latance display returns, and the states (D0-7 & A0-7) are false. That’s why I prefer my project.

Bonjour, j’ai réussi à faire fonctionner ton code, j’ai eu certe quelques difficultés mais j’ai fini par réussir. Merci pour ce partage.
J’aurais une question, je souhaite envoyer des commandes du genre : http://IP-SPARKCORE?VARIABLE1=VALEUR1&VARIABLE2=VALEUR2 … (bref si je ne me trompe pas des variable POST)
Comment faire pour les réccupérer ? J’ai vu qu’elles étaient présente dans hr.URL() avec le reste de l’url, mais existe-t-il une fonction pour les extraire ou dois-je en faire une ?

D’avance merci pour toute aide apportée.