Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building an API in 60 seconds, without any server setup

api.blockspring.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Building an API in 60 seconds, without any server setup

#61

Post by deadgrey19 »

bwood wrote: post #58
deadgrey19 wrote: post #56

I really don't understand what's happening here. I think we use the term "API" and "server" differently. When I think of an API, I think of a library or something that I can link to. For example the POSIX API, or the P-Threads API. These are available in one way or anther from any language. This seems to think very differently about APIs. As if APIs are somehow tied to a specific language? When they use the term API,…

I think the idea is that if you have a useful script, you can set it up here just once and it's automatically wrapped with an HTTP-based interface so you can use it like an API. Now you can use that script from any Internet-connected device, with basically zero setup on each device. I'm not sure if I can think of something I'd want to use it for, but this is an interesting idea and a great proof-of-concept implementa…

But why not just use the script directly on that device? Since the interfaces to the "API" are things like Python, Ruby, QJuery etc, you still need your internet connected device to be running an actual scripting language. At which point, you might as well just script it locally rather than proxying through a (potentially insecure) connection to a remote server on the internet to run it for you. I just don't understand the benefit?

Re: Building an API in 60 seconds, without any server setup

#62

Post by bwood »

deadgrey19 wrote: post #61
bwood wrote: post #58

Earlier quoted context omitted.

I think the idea is that if you have a useful script, you can set it up here just once and it's automatically wrapped with an HTTP-based interface so you can use it like an API. Now you can use that script from any Internet-connected device, with basically zero setup on each device. I'm not sure if I can think of something I'd want to use it for, but this is an interesting idea and a great proof-of-concept implementa…

But why not just use the script directly on that device? Since the interfaces to the "API" are things like Python, Ruby, QJuery etc, you still need your internet connected device to be running an actual scripting language. At which point, you might as well just script it locally rather than proxying through a (potentially insecure) connection to a remote server on the internet to run it for you. I just don't understa…

The APIs only have a single interface, and that is HTTP. All the examples are just different ways of making an HTTP request, whether through the curl command or a full-blown language. Hitting this API has only one requirement: something capable of making HTTP requests.

Running the script directly requires a correctly-configured environment for each scripting language you want to support on each device. If a script has additional dependencies or libraries, those must also be installed locally if you want to run the script locally. By putting the script behind an HTTP API, it just needs to be correctly configured once on a single device (the API server), and then the requirement for using the script on all other devices is just plain old HTTP.

Suppose you have five different scripts each written in a different language (because languages have their own strengths and weaknesses). And suppose you need to run all of these scripts on three completely different devices (say, a phone, a laptop, and an Arduino). If you want to run the scripts directly on each device, then you need to set up 5*3=15 runtime environments and make sure they all function correctly (and don't break with updates). To save effort, it might make sense to put these scripts behind an HTTP API, and then just use simple HTTP requests from each device to access all scripts in a uniform manner. Note that in reality, you'll probably want to be targeting much more than three devices, so the savings can stack up quickly.

Re: Building an API in 60 seconds, without any server setup

#63

Post by hackerews »

deadgrey19 wrote: post #61
bwood wrote: post #58

Earlier quoted context omitted.

I think the idea is that if you have a useful script, you can set it up here just once and it's automatically wrapped with an HTTP-based interface so you can use it like an API. Now you can use that script from any Internet-connected device, with basically zero setup on each device. I'm not sure if I can think of something I'd want to use it for, but this is an interesting idea and a great proof-of-concept implementa…

But why not just use the script directly on that device? Since the interfaces to the "API" are things like Python, Ruby, QJuery etc, you still need your internet connected device to be running an actual scripting language. At which point, you might as well just script it locally rather than proxying through a (potentially insecure) connection to a remote server on the internet to run it for you. I just don't understa…

Bwood - you just described it more clearly than I ever have. Thank you.

Re: Building an API in 60 seconds, without any server setup

#64

Post by tlrobinson »

deadgrey19 wrote: post #56

I really don't understand what's happening here. I think we use the term "API" and "server" differently. When I think of an API, I think of a library or something that I can link to. For example the POSIX API, or the P-Threads API. These are available in one way or anther from any language. This seems to think very differently about APIs. As if APIs are somehow tied to a specific language? When they use the term API,…

Huh? The term "API" is commonly applied to HTTP endpoints intended to be consumed by other programs, aka "web services".

Re: Building an API in 60 seconds, without any server setup

#66

Post by hackerews »

codygman wrote: post #60
hackerews wrote: post #36

Earlier quoted context omitted.

Language support is super easy to add. Any list of libraries you'd really want with Haskell?

Some random highly used libraries: containers, bytestring, mtl, text, transformers, time, array, aeson, split, blaze-builder, blaze-html lens, safe, resourcet I'm sure aeson examples would be very popular. mtl/transformers examples for those who are getting to them in the learning process. Here is a complete list of the top reverse dependencies for libraries on hackage: https://docs.google.com/spreadsheets/d/1o7K_tED…

You are brilliant. Thank you so much.

Re: Building an API in 60 seconds, without any server setup

#67

Post by donpinkus »

giancarlostoro wrote: post #65

I'm surprised they don't monetize this, I think it's really neat, especially selling the solution for private use.

Truth is most people's APIs really cost us nothing to run, so we'd rather not charge for it :P

I'm a really big believer in sites that provide a ton of utility for free, and only charge you when you're actually costing the company something.

That said if you do want to use a ton of CPU, that gets expensive for us - so we may make paid accounts for people that use CPU heavy API's. We realized Blockspring would still be a lot cheaper than keeping your own EC2 server up all the time, so that's sorta cool!

Also if you wanted it set-up locally at your company and 24/7 phone support (from the two of us), we'd have a paid account to cover our time.

Obviously if you have ideas let us know!

Re: Building an API in 60 seconds, without any server setup

#69

Post by _dps »

tlrobinson wrote: post #64
deadgrey19 wrote: post #56

I really don't understand what's happening here. I think we use the term "API" and "server" differently. When I think of an API, I think of a library or something that I can link to. For example the POSIX API, or the P-Threads API. These are available in one way or anther from any language. This seems to think very differently about APIs. As if APIs are somehow tied to a specific language? When they use the term API,…

Huh? The term "API" is commonly applied to HTTP endpoints intended to be consumed by other programs, aka "web services".

In context, you're right of course. But you might be underestimating the number of non-web programmers who have this reaction. I know many such people, and many have asked me "The term API predates the web; In what sense is this an API?".

For such people, I propose the metaphor that HTTP APIs are a form run-time linking where the root URL (api.example.com) is the "library" and the valid URIs (api.example.com/list_of_cats) are the exported "symbols" you can reference from your program. Performing a GET on such a "symbol" is like dereferencing the pointer you get from calling dlsym. The 400 and 500 range status codes are like dlsym's error codes: 404 is a failure to find the symbol, 500+ is various run-time errors, etc.

Re: Building an API in 60 seconds, without any server setup

#70

Post by deadgrey19 »

_dps wrote: post #69
tlrobinson wrote: post #64

Earlier quoted context omitted.

Huh? The term "API" is commonly applied to HTTP endpoints intended to be consumed by other programs, aka "web services".

In context, you're right of course. But you might be underestimating the number of non-web programmers who have this reaction. I know many such people, and many have asked me "The term API predates the web; In what sense is this an API?". For such people, I propose the metaphor that HTTP APIs are a form run-time linking where the root URL (api.example.com) is the "library" and the valid URIs (api.example.com/list_of_…

Thank you! Perfect response. I'm a systems programmer, mostly working in VHDL, C and assembly. I use and write API's all the time. I've never used an "API" over HTTP before.

I think the confusion comes from a slow divergence of terminology. Web providers offered "API's" to allow people to access their services, these were kind of API's in the sense that an application could use them. However, it seems that for the web development community has begun to think that an API and an HTTP based API are synonymous (they are not!). Hence my confusion here.

Post reply on HN