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.
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.
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)
I meant plain HTTP without another layer of complexity on top. REST to me is someone's PhD thesis, the man who designed HTTP. When I read it, I interpreted it as an argument for the use of HTTP (his baby) and the benefit of keeping things as simple as they can be kept. But lots of people seem to have taken it to be some sort of API. I'm not sure anyone can definitively say what is and what is not "REST", except Fielding himself. All I see is disagreement. I'm in favor of simplification (or more specifically, not adding complexity where it is not needed). Whether that is "REST" or whatever, I don't know. Using just HTTP is simpler. It worked fine before these other things like XML, SOAP and JSON came along. (And I have a hunch that's why he wrote a thesis to illustrate how HTTP can be used for most things people are trying to do with XML, SOAP and JSON.) That's all I know.
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!
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.
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.
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.
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.
25 comments
[ 2.7 ms ] story [ 65.2 ms ] threadSome 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.
Nah, it would never work. Pay no mind. I'm just a fool.
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!
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.
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.
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.