News for hackers. Stuff that matters.
Re:Virtualizing APIs with Go and Python by skywhopper on Friday December 11, 2015 @11:09AM (#10717876)
I don't think "virtualization" is quite the right word. "Middleware" is better. "Protocol rewriting" might be more honest. Though in my day we just called this a "hack".

It's certainly nothing new, whether you do it with a CGI script a fancy rewrite module on your reverse proxy or a network "appliance" endpoint like a BIG-IP. It's definitely something every good ops or devops person should be able to pull off to fix those unfixable problems that crop up from vendor intransigence or developer pushback.

Re:Virtualizing APIs with Go and Python by nly on Friday December 11, 2015 @10:09AM (#10717473)
Isn't this just CGI, straight out of the 90s, but with a needless cycle through JSON?
Re:Virtualizing APIs with Go and Python by 5h on Friday December 11, 2015 @10:28AM (#10717594)
That's kind of what i was thinking - somewhere between good ol' cgi and a reverse proxy ....

Unfortunate because I'm semi-looking for a simple service that will let me configure a stateful new frontend to an old API - title made me think it might be along those lines.

Re:Virtualizing APIs with Go and Python by rakoo on Friday December 11, 2015 @11:32AM (#10718017)
There's a huge difference: CGI is the ultimate backend in the HTTP stack, while this allows you to run scripts as middleware (ie modifying the response headers/body based on previous processing)
Re:Virtualizing APIs with Go and Python by bmurphy1976 on Friday December 11, 2015 @02:06PM (#10719111)
Not necessarily true. CGI could shell out to other CGI code if it wanted to. Turtles all the way down.
Re:Virtualizing APIs with Go and Python by rakoo on Saturday December 12, 2015 @11:15AM (#10723169)
What if the backend is not CGI ? What if I want to use a script to gzip the output of a backend that doesn't compress anything ? Of course you can just call that backend through HTTP, but then you add another huge dependency on your little script that should just be as simple as "gzip -c -"
Re:Virtualizing APIs with Go and Python by sdegutis on Friday December 11, 2015 @10:18AM (#10717536)
Correct.
Re:Virtualizing APIs with Go and Python by boomlinde on Friday December 11, 2015 @12:39PM (#10718470)
readlines() just to pick the first seems weird if you expect a single line. I'd read the whole thing in one go with read(). Then I start wondering if it wouldn't make more sense to keep the stream open and just iterate over new messages line by line and avoid the overhead of loading an executable, importing libraries etc. on every request
Re:Virtualizing APIs with Go and Python by Lobster101 on Friday December 11, 2015 @10:26AM (#10717573)
It is similar, but one advantage is that you can run your existing CGI scripts (C/C++/perl/ ...) without a remote web server. That interests me as it would allow re-use of some existing scripts and it would also allow me to wrap some legacy interfaces.
Re:Virtualizing APIs with Go and Python by _RPM on Friday December 11, 2015 @10:40AM (#10717688)
`data = sys.stdin.readlines()` in their Python script. Is it common to not check return values of functions in Python land? I might be too disciplined coming from a C background, but what if getting the data fails?
Re:Virtualizing APIs with Go and Python by detaro on Friday December 11, 2015 @10:44AM (#10717718)
Then the function throws an exception and the program terminates, since there isn't anything useful it can do about the situation. What would you suggest it to do if it can't read from stdin?
Re:Virtualizing APIs with Go and Python by jaytaylor on Friday December 11, 2015 @01:10PM (#10718739)
Direct link to Hoverfly source code: https://github.com/SpectoLabs/hoverfly
Re:Virtualizing APIs with Go and Python by carlisle_ on Friday December 11, 2015 @01:42PM (#10718964)
Why is there image and whitespace that takes up >50% of the width of the page? It makes it so obnoxious to read.
Re:Virtualizing APIs with Go and Python by mring33621 on Friday December 11, 2015 @12:50PM (#10718553)
So...AOP for web calls.