The reason I'm doing this is because I hijacked Serial1 to quickly transmit data between Arduino and Linino via this discussion:
The problem with the methodology is that it breaks the Bridge between Arduino and Linino.
My project basically streams data off of the Arduino to Linino which then transmits the data via direct socket connections to other devices - PC, RPi, AWS etc. But I want to be able to control and configure my Arduino via a simple web interface - hence the REST server.
Well, that is the disadvantage of bypassing the Bridge and rolling your own communications. The Bridge can do everything that direct communications can do (perhaps a bit slower) and it can do so much more. But direct communications can't do all of the other things that the Bridge can do, or at least not without a LOT more work.
The short answer is that since you bypassed the Bridge library, you cannot implement a REST API in the sketch unless you write all of the infrastructure yourself. You have three choices:
Go back to using the Bridge
Write the equivalent of the Bridge communications API yourself
Implement your API on the Linux side.
Option 1 might be viable for you. Unless you are passing huge amounts of data over the serial port, or need sub-microsecond latency on the communicated values, a Process class instance should be able to do everything your direct communications can do, plus allow you to use the rest of the Bridge features. What you will need to do is not automatically launch your Linux side process. Instead, create a Process object in your sketch to launch it. Then wherever you are reading or writing to Serial1, read or write to your process object instead. Both Serial1 and the Process class derive from Stream, so the exact same read/write/print/available/etc functions work with both. On the Linux side, your process needs to read/write STDIN and STDOUT instead of /dev/ttyACM0. Once you do this, you are free to use the rest of the Bridge features.
Option 2 is simply too painful to consider. :o
Option 3 might be the way to go in your case, or at least that's how I would do it. I have used the Bottle framework in Python to implement web applications, including a REST API. I'm sure Flask or other frameworks can do it as well. I think it's easier than doing it in the sketch, and it's MUCH faster and more reliable. Recently, I tried implementing a REST API in the sketch using the traditional Bridge method. It worked, but took a noticeable time (close to a second) to service a request, and it would crash/hang daily. I then replaced it with a REST API written in the Bottle framework, and the response is virtually instant (things are updated before I can move my mouse from the web page button) and it just plain runs forever.
Your only challenge with option 3 is how to communicate the data in and out of the Bottle application to the rest of your system. The inter-process communications are left as an exercise for the reader...