While your API is well-done from a technical perspective, what I'm really impressed of is your client ecosystem. There are bindings for pretty much all relevant languages, even COBOL and bare x86 assembler. And most are even part of the language core, so you don't even need a library. That must have required some negotiation skills!
42 as a Service
61–69 of 69 posts
Re: 42 as a Service
#62Re: 42 as a Service
#63Re: 42 as a Service
#64Do you plan to release it as open source in the event of getting acquihired? On a more serious note, if SaaS APIs are function calls, this is an equivalent of a constant. Let's build a cloud programming language! Anyone wants to write cons, car, cdr, cond, quote and lambda SaaSes?
how would you "glue" everything together? seriously, something really cool could come out of this...
As chained url encoded parameters?
http://example.com/exec?http%3A%2F%2Fexample.com%2Fsum%3Fhtt...
Re: 42 as a Service
#65Do you plan to release it as open source in the event of getting acquihired? On a more serious note, if SaaS APIs are function calls, this is an equivalent of a constant. Let's build a cloud programming language! Anyone wants to write cons, car, cdr, cond, quote and lambda SaaSes?
Webshell.io tried to use JavaScript as cloud programming language, transforming every API endpoint/API call into a JavaScript object. Then you could script APIs and SaaS using JavaScript.
Check this article on why JavaScript is the glue for APIs http://apieconomist.com/blog/2013/6/26/api-days-are-here-aga...
Re: 42 as a Service
#66text/html for this?