4 ms·

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 somethi

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, do they maybe mean library? I think that under the hood, the idea is that, if you want to do something, in another language (rather than just writing it in the language) you somehow generate a stub in both languages and then proxy through a (network?) connection? To make this more complex, it seems that the proxy connections are not just on the local machine, but over the internet to another machine. Presumably you have to pay for this? Am I right? This seems like a lot of effort to go through just to avoid figuring out how to do something directly. With really sucky performance implications. I guess it depends on what you're doing. Most languages support a foreign interface to C, so maybe that is a more sensible way to do this rather than setting up "servers" and tunnelling commands and data back and forth. EDIT: I just had another look at the website. So, when they use the term API - it would seem that they mean some sort of an HTTP based web interface? The idea is that you have some kind of script that does something for you and you can query it from you local script. I still don't understand why you'd want to do this over running it locally?

hackerews 12y ago
Hey Deadgrey, You're totally right. I'm not sure API is the best word for it, but haven't found a better one. Would love your thoughts! I've heard a bunch of crazy usecases from HN over the past day but my original one was to simply take some of the python and R scripts I had, and without much work (a few clicks actually) be able to execute them from my frontnd js, or from rails workers. It worked really well so we decided to see if others might find it useful too. It's badass to see what others are coming up with in the API Library, hoping that can be a valuable page for everyone. And I imagine when we figure out fair pricing, we can actually make this significantly cheaper than a dedicated server for these processes. Please, continue to send feedback like this. You're awesome. -Paul@blockspring.com 3128347265
bwood 12y ago
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 implementation. I think perhaps the most interesting part of this is that they're apparently spinning up/down Python (and other languages) sandbox environments on the fly, nearly instantaneously.
- deadgrey19 12y ago
  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?
  - bwood 12y ago
    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.
tlrobinson 12y ago
Huh? The term "API" is commonly applied to HTTP endpoints intended to be consumed by other programs, aka "web services".
- _dps 12y ago
  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.
  - deadgrey19 12y ago
    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.

hackerews 12y ago

Hey Deadgrey, You're totally right. I'm not sure API is the best word for it, but haven't found a better one. Would love your thoughts! I've heard a bunch of crazy usecases from HN over the past day but my original one was to simply take some of the python and R scripts I had, and without much work (a few clicks actually) be able to execute them from my frontnd js, or from rails workers. It worked really well so we decided to see if others might find it useful too. It's badass to see what others are coming up with in the API Library, hoping that can be a valuable page for everyone. And I imagine when we figure out fair pricing, we can actually make this significantly cheaper than a dedicated server for these processes. Please, continue to send feedback like this. You're awesome. -Paul@blockspring.com 3128347265

bwood 12y ago

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 implementation. I think perhaps the most interesting part of this is that they're apparently spinning up/down Python (and other languages) sandbox environments on the fly, nearly instantaneously.

deadgrey19 12y ago
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?
- bwood 12y ago
  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.

tlrobinson 12y ago

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

_dps 12y ago
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.
- deadgrey19 12y ago
  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.