

Show HN: libsaas, it's libcloud for SaaS - dmarinoc
http://libsaas.net

======
bryanh
Very impressive. At Zapier we're building an internal tool very similar to
this (and in Python to boot). Maybe we should hook up?

~~~
wulczer
That would be awesome! Hit us up on contact@ducksboard.com (or my profile
email)

------
jeffbarr
Isn't this what web services were promising us? Cool library, but ideally the
SaaS apps would export APIs for this functionality.

~~~
wulczer
The lowest common denominator of SaaS APIs is HTTP. Apart from that, everyone
does it different.

Some use JSON, some use XML, some use SOAP... Sometimes you authenticate with
Basic authentication, sometimes you use OAuth 1.0 and need to sign each
request, sometimes it's OAuth 2.0 and you just need the token. Oh, and the
actual GET parameter for the token is different, too...

There are APIs where you need to set a 'X-API-Version' header to something, or
you'll get weird results. The list goes on...

The goal here is to hide all that crap from developers and focus on achieving
the desired result.

~~~
thereason
Instead of hiding it, why don't we ditch it altogether? HTTP is simpler, more
direct and easier to debug. By sticking to HTTP, we might get closer to a
situation where "everyone does it the same". Life might be easier.

Nah, it would never work. Pay no mind. I'm just a fool.

~~~
drivebyacct2
All of the things in that post use HTTP. (Though SOAP doesn't require HTTP).
Did you mean REST? Even then, people often don't get it right, and it's still
not as nice a language specific API. (er, application specific api)

------
olegp
I have written something similar in JavaScript:
<https://github.com/olegp/restwrapper>

~~~
alttab
What about cross domain requests?

~~~
olegp
It's server side JavaScript with an option to proxy to the browser if needed.

------
someone13
Didn't want to test this, in case it's actually a problem, but the usage
examples seem to include your Mailchimp key. You may want to remove that :-)

~~~
wulczer
It's not a real key, just a random hash to make the example feel more real.
Seems we hit the Uncanny Valley of code examples ;)

------
jmonegro
I quite like it. I'll get to porting it to Ruby.

~~~
wulczer
There were some very sketchy plans about making this multilanguage... The best
we could come up with was writing a small C module that would call Python code
and that you could wrap in other languages.

If anyone has a better idea on how to keep the logic in one language, but make
it accessible to everyone (preferably without inventing a whole DSL, that
would end up being just like a real programming language, but worse), please
speak up!

~~~
drivebyacct2
>a small C module that would call Python code

Seems strange to me. Seems like for a lot of this, where it's often HTTP based
anyway, you could implement much of it in C without it being a complete
nightmare.

~~~
alttab
Not very practical if you needed to deliver the integration over the Internet
in a web app

~~~
drivebyacct2
Huh? We're talking about a library to use in applications, web apps or
otherwise, and finding ways to make them usable with multiple languages. That
screams "C", as every language I can name can call C code. If they delivered
libsaas as a C library, everyone can write a small wrapper and then have it in
their favorite language.

Honestly, I don't know what "deliver integration over the Internet in a web
app" means in this context at all.

I'm sure there are already C libraries to make REST calls easy and the rest is
just creating the proper queries and parsing responses into usable structures,
etc.

~~~
alttab
I ask because I'm solving the "cloud API" problem right now too - but my
context and environment require that we can solve the problem with internet
technologies and not compiled C code. I can't really go into too much detail
yet.

~~~
drivebyacct2
... what?

Like I said, the things you're saying are either vague to the point of
misleading or you're extremely confused about some very basic things...

I'm a huge fan of "web techonologies". Seeing as Go is a great way of writing
web services that back web apps, it's a pretty good fit. There are thousands
of things that aren't possible, and never will be with "web technologies".
Every web technology is hitting some web service somewhere that's powered by
code that does _not_ run in a web browser.

"Solving the Cloud API problem" sounds like... well it's sounds like a bunch
of jargon speak.

