Factor out basic REST server from mode,digital,analog and variable support

[grubbyhacker]

Thanks for the great work. I looked all over for a rest server for the esp8266 and all arrows come here. For absolute beginners its very useful. For more advanced projects, however, I think this library is carrying around support for too many features that won't be used and that cause binary size bloat. Have you considered factoring out the REST server and user-defined function handlers into a separate library? I think that would be more useful in the long-term. The direct REST addressing of I/O pins is cool, but I would prefer to have it as another library built on top of the core REST library. That way I don't have it all compiled (and working!) in my live IOT device.

[marcoschwartz]

Thanks! I think this is a nice suggestion, however to actually implement I'd need to wait until Arduino comes up with a real management of dependencies between libraries. Otherwise it will create a lot of confusion for current users of the library if they have two libraries to install :)

[shlomiassaf]

For now it can be done by building the root library and adding the functionality using a some sort of a bundler/builder like they do on JS libraries... so you can remove some portions of the code and create a new "slim" release parallel to the current one (i.e aREST_min.h). This requires a re assessment of the code to create those split points... a lot of work :)

But, if its too much work for now, how can I cancel these functions, lets say the device operates an environment which is not fully secured, digital/analog/mode as public exposed functions are a serious security issue.

[marcoschwartz]

Indeed, a lot of work is not really what I need at the moment :) I am just trying to understand: what would really be the use of aREST for you if it's stripped down from all the control functions?

[grubbyhacker]

Personally I need a simple REST server that does not expose all of my GPIO pins. This can be dangerous - if say one of those pins is controlling a relay... I think your point with aREST is to be a simple-to-use REST API to GPIO pins first, and a general purpose REST server second. That's a great idea, but the Arduino community could also use a REST Server with a more or less complete implementation of HTTP (including post and retrieving http request bodies...) and without the builtins that aRest comes with.

aREST does not have to be the project that morphs into that other thing :-). Its usually best to do a 1-2 things really well, rather than to do everything! The reason that I created this issue was because when I first read the aREST docs I thought it was aiming to provide that general purpose REST Server implementation. Re-reading the first sentence today I think "A simple library that implements a REST API for Arduino" means rather: A REST API to Arduino IO pins.

[shlomiassaf]

I agree, I would love to have a REST API with minimal effort but I don't want to expose IO pins without controlling it, I need a logic layer in between.

For example, imagine an IoT device controlling some sort of an engine. Anyone can activate the engine by calling the IO pin controlling the state of the engine (on/off)

The engine can overheat, how would I implement a fail safe protection logic to turn it off when overheating? Of course I can use timers to controller that but its not right and even so, it will pop another issue, what if the controller must enforce a 5 minute delay between engine starts... now there is no way to control that.

Again, its nice to have an API but if it has access to IO without enabling a security its only usable for internal devices without external access.

[saliehendricks]

Maybe a simpler option to protect certain IO pins could be for aREST.h to use a static define array storing the pins that it should not interact with. Then when parsing the command just check if that requested pin is in the ignore[]. @shlomiassaf could be done in a branch perhaps. I am no good with microcontroller code so I would be interested in problems this may create?

[guiguid]

Hi, by default your aRest API is for prototyping and very nice ! But when the project is mature and connected to real word ( motor, gate ....) it will be nice to disable all write and mode changing on pins ! You can keep digital read, analog read ( if pin is Input), but disable writing, it can be very dangerous. Actually, I can't use your project in my home automation because of direct writable I/O Thanks. Guillaume

[romuye123]

@guiguid Agree with your point. This project is very good for prototyping purpose. wont be good to use for a LIVE project. will you please let me know which protocol(& which library) you used for communication between client(s) and Arduino? Client can be a mobile app / local machine or any another machine around the world.

[saliehendricks]

aRest Pro uses an api key to add a layer of security. Pretty standard as far as API security goes. If you want more security and control over what urls can be called you can create a webserver (say on a Pi) that relays the comms to the aRest cloud. You could go a step further and create your own mqtt server and still use aRest. Your webserver can have any security implementation you like.

Saying aRest is not for production use is prob down to how you implement it rather than the library itself.

I use this library extensively in a my live home automation projects

[G4HDU]

I also think a slim version which just allows standard rest interface would be beneficial. Rather than have two libraries why not just use #ifdef #endif round the additional features. Defaul to the full version but allow the coder to #define ARESTSLIM to skip the enhanced parts.