Even though I already agree with the premise, this article seems to go on for a long time without convincing anyone of anything. Needs some examples or something.
And what we really need is a universal API consumer for when every municipality and your toaster has an API in different format.
Hey there, this is the author. I agree it's kind of a slog. It was tough to balance bringing in non-programmers to the arguement and getting into the weeds of what I'm talking about. You should see the scraps that didn't make it in. I wrote some pseudo-code for my personal API, including how beers affect the loudness of my voice.
To be honest, a little example like that might be perfect. Maybe I'm not the right target audience but I was hoping for that sort of exploration of how disparate information sources could be made to work together.
Serious question: why not strive to make a filesystem the universal service API? Filesystems offer built-in CRUD semantics, notions of listing/grouping data by key (i.e. directory), notions of read/write/search permissions, and notions of tagging records with arbitrary attributes.
Advantages:
* It doesn't take much effort to create a filesystem API. The service only needs to expose 12 basic methods to get off the ground (open, close, read, write, creat, unlink, mkdir, opendir, readdir, closedir, rmdir, stat). It could go on to implement trunc, mknod, rename, link, and maybe others if it wanted, but that would depend on whether or not there's a semantic "mapping" of these methods to the service's features. Also, if per-record attributes are needed, then there's only 4 additional methods to implement (getxattr, setxattr, listxattr, removexattr). Higher-level operations, like transactions, can be implemented in a client library as compositions of the 12 basic methods.
* It doesn't take much effort to understand a filesystem API either. Programmers usually learn how to interact with a filesystem early on, so they'll understand the basic semantics of your service without much more experience. This lowers the barrier to entry for writing applications that use your service. Moreover, existing tools that expect to interface with a filesystem can now interface with your service's data with little/no modification.
* If the filesystem becomes the standard service API, then applications can trivially create mash-ups of data from multiple services by mounting them within the application's own filesystem namespace.
* Despite having a fixed API, the filesystem doesn't constrain the semantics of the service, since the service can namespace data by the extra semantics that apply. For example, records under the /Users/ directory could be made to have tighter consistency semantics than records in /TemporaryData/. Another example, writes to files in /StruturedFileData/ could be rejected if the write() doesn't contain properly-formatted data. A third example: files in /EncryptedData/ could each be required to have an extended attribute called "encryptionKey" that contains the symmetric key needed to decrypt the file. A write() on a file will fail until the "encryptedKey" attribute is set.
* For service functionality that for whatever reason cannot be exposed via a filesystem (and to be honest, I'm having a hard time thinking of any), the filesystem still lets you "emulate" RPC by creating or reading a file whose path describes the serialized method and arguments. For example, fd = open("/API/this_is_a_method/and_this_is_the_first_arg/and_this_is_the_second_arg/etc", O_RDONLY) would send the request, and read(fd, 65536) would get the result. The /API/ namespace would forbid opendir() and readdir(), and the path resolution implementation would treat the rest of the path after "/API/" as the method name and arguments (instead of directories to be searched).
I hope we're on our way towards that already. What you're describing sounds like what REST should be, in a perfectly implemented world. The problem is there are very few APIs that get it right. Github is the only one I can think of immediately - e.g https://api.github.com/repos/jcnelson/wish/events
By the way, the idea of the API as a filesystem (and the Internet as a network of filesystems) is something I've thought about a lot recently, and I'm in the process of building a shell around the idea. This includes `cat`ting URLs as if they were files, mounting endpoints as directories, and piping between services as processes... Figured I'd share due to the tangential similarity to WISH (it's even called wwwsh): https://github.com/spro/wwwsh
Whoever decides to write this API, please don't do it in SOAP.
Seriously, though, that would be the issue with anything that tries to standardize something so broad--eventually, factions would form and it would self destruct.
It seems that the current attempt to do anything like this is SNMP with its wealth of standardized MIBs.
Of course, we could ignore all that because it’s not new and cool, and instead fight over what’s new enough to be considered. (SOAP! No, REST! Etc.)
Or, alternately, is this not what the Internet is? I.e. a standardized way for things to access other things, the exact protocols to vary depending on the things in question?
9 comments
[ 3.0 ms ] story [ 28.9 ms ] threadAnd what we really need is a universal API consumer for when every municipality and your toaster has an API in different format.
Actually no, no one should ever see that.
Advantages:
* It doesn't take much effort to create a filesystem API. The service only needs to expose 12 basic methods to get off the ground (open, close, read, write, creat, unlink, mkdir, opendir, readdir, closedir, rmdir, stat). It could go on to implement trunc, mknod, rename, link, and maybe others if it wanted, but that would depend on whether or not there's a semantic "mapping" of these methods to the service's features. Also, if per-record attributes are needed, then there's only 4 additional methods to implement (getxattr, setxattr, listxattr, removexattr). Higher-level operations, like transactions, can be implemented in a client library as compositions of the 12 basic methods.
* It doesn't take much effort to understand a filesystem API either. Programmers usually learn how to interact with a filesystem early on, so they'll understand the basic semantics of your service without much more experience. This lowers the barrier to entry for writing applications that use your service. Moreover, existing tools that expect to interface with a filesystem can now interface with your service's data with little/no modification.
* If the filesystem becomes the standard service API, then applications can trivially create mash-ups of data from multiple services by mounting them within the application's own filesystem namespace.
* Despite having a fixed API, the filesystem doesn't constrain the semantics of the service, since the service can namespace data by the extra semantics that apply. For example, records under the /Users/ directory could be made to have tighter consistency semantics than records in /TemporaryData/. Another example, writes to files in /StruturedFileData/ could be rejected if the write() doesn't contain properly-formatted data. A third example: files in /EncryptedData/ could each be required to have an extended attribute called "encryptionKey" that contains the symmetric key needed to decrypt the file. A write() on a file will fail until the "encryptedKey" attribute is set.
* For service functionality that for whatever reason cannot be exposed via a filesystem (and to be honest, I'm having a hard time thinking of any), the filesystem still lets you "emulate" RPC by creating or reading a file whose path describes the serialized method and arguments. For example, fd = open("/API/this_is_a_method/and_this_is_the_first_arg/and_this_is_the_second_arg/etc", O_RDONLY) would send the request, and read(fd, 65536) would get the result. The /API/ namespace would forbid opendir() and readdir(), and the path resolution implementation would treat the rest of the path after "/API/" as the method name and arguments (instead of directories to be searched).
By the way, the idea of the API as a filesystem (and the Internet as a network of filesystems) is something I've thought about a lot recently, and I'm in the process of building a shell around the idea. This includes `cat`ting URLs as if they were files, mounting endpoints as directories, and piping between services as processes... Figured I'd share due to the tangential similarity to WISH (it's even called wwwsh): https://github.com/spro/wwwsh
Seriously, though, that would be the issue with anything that tries to standardize something so broad--eventually, factions would form and it would self destruct.
It would be fun in the mean time, though.
Of course, we could ignore all that because it’s not new and cool, and instead fight over what’s new enough to be considered. (SOAP! No, REST! Etc.)
Or, alternately, is this not what the Internet is? I.e. a standardized way for things to access other things, the exact protocols to vary depending on the things in question?