FFI is a mechanism by which a program written in one programming language can call routines or make use of services written in another. As far as we know, client can invoke RESTFul API via HTTP to call web server. So is RESTFul paradigm or HTTP a form of FFI?
Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
1–10 of 19 posts
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#2Not being an expert on the topic, to me FFI implies a tighter coupling between caller and called, typically that they will be in the same memory space.
I would consider RESTful and HTTP APIs closer to remote procedure calls (RPC).
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#3No. It's RPC (remote procedure call), it's not FFI or has anything to do with FFI, unless you have a different definition than mine.
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#4You are correct. When you develop a FFI, you solve many of the same issues that are solved in RPC (remote procedure calls).
When you convert Lisp objects to C objects and vice versa across the call, this is very similar to marshalling and unmarshalling remote procedure call arguments.
The different representations and memory management of the objects are such that the two domains are often like different machines.
If you use FFI in reverse, you could use it to implement RPC. So that is to say, you can register a FFI callback in some C code which will pass some structure into the Lisp image. It gets converted to a Lisp structure. But what is that? Marshaling. The Lisp code could pass it over a network as an S-expression (further marshalling). The other side receives it, converts it to a Lisp structure, and then calls a FFI function into C code, where that becomes a C structure. Thus a RPC was achieved, leveraged by FFI.
The minimum requirements to legitimize the use of "foreign function interface" is that one domain activates a call in another domain, communicating data flows, which undergo a change in data representation.
The consideration of different programming languages is a red herring! Two different languages could have a very similar native representation. For instance, if we have Pascal and C modules directly calling each other because they use the same calling conventions and data representations like "record of two 32 bit integers", that is not FFI. C calling assembly routines and vice versa isn't FFI.
"Foreign" doesn't so much mean "Foreign language" but "Foreign run-time/VM/data model.". Under the hood it might all be x86 machine code, which is the same language!
Typically FFI denotes the coupling of some managed environment with something closer to the metal, but other situations/combinations can fit the concept.
(Claimer: I've authored a well-developed FFI, as well as more than one remote procedure implementations, with data-description-driven marshaling/unmarshaling of binary objects. So you don't have to take anything here with any salt.)
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#5No. It's RPC (remote procedure call), it's not FFI or has anything to do with FFI, unless you have a different definition than mine.
The difference would be the number of layers of indirection.
FFI implies a binary interface with some compiled shim layer, and RPC uses a network stack.
Ionic vs. Covalent bonding, if you will?
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#6No. It's RPC (remote procedure call), it's not FFI or has anything to do with FFI, unless you have a different definition than mine.
The difference would be the number of layers of indirection. FFI implies a binary interface with some compiled shim layer, and RPC uses a network stack. Ionic vs. Covalent bonding, if you will?
RPC's can be abstracted so that you don't know. E.g Microsoft COM: same call to call an in-process COM object versus DCOM. Within the process, it could be "apartment threaded": the other domain has its own thread, which receives the argument material as a request, does it, and replies. (Kind of thing). Or it could be direct: your thread calls the function.
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#7Conceptually, no, as others have said. The various RPC protocols- some of which can be inefficiently layered on top of HTTP- are FFIs.
FFIs are conceptually simple- call and response on the wire with a schema ABI.
The conceptual model for HTTP is much more complex. It is for synchronizing portions of a collection of data models between two systems.
HTTP includes expectations for an extensible set of data types that may be transferred, as wholes or in parts. These data types have identities and a variety of encodings and representations, and they may occasionally be taxonomically relocated, or may disappear altogether.
HTTP includes a robust caching layer and support for both transactional and streaming interactions.
In HTTP/2 it allows the client to request many data types at the same time and for the server to optimize for delivery even for elements the client has not yet requested but the server knows it will need.
The acronym REST- Representational State Transfer- captures the conceptual goal for the HTTP protocol. A client/server system has complex state on both sides, and needs a protocol that is aware of the complexities of transferring that state. It is much richer and deeper than FFI.
Cheers.
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#8A while back it occurred to me that one of the main benefits of microservices is that each team, and even each service, can have its own language/stack. Beyond accommodating people's preferences this allows the organization to experiment with different languages more easily. All they need is an HTTP library
So yeah, I'd agree that it's a kind of FFI. Or maybe even a "lingua franca"
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#9How pedantic do you want to be about it?
I'm sure people will tell you "No, that's not true FFI." It's close enough, if you generalize REST to a sort of RPC where HTTP is the transport/protocol.
There are problems you run into when you use "true" FFI -- namely ABI/binary compatibility (you're beholden to compiler or OS behaviors) and the fact that non-native languages can't directly communicate with you.
Doing something over the network has a performance penalty, and there's marshalling costs involved.
But IMO, if you expose an IPC or socket-based API (rather than a C ABI) I'm not sure very many people could fault you.
Re: Is RESTFul Paradigm a Type of FFI (Foreign Function Interface)?
#10Ivory to tower statement: Architecture calls these components and connectors. A component can be something as small as a function or as big as a monolith. A connector specifies the connection and its attributes between two components.
However, connectors can be of any form. They can be based on memory/processor (like local function calls), based on network protocols (like http calls), databases (a system a drops a record another one picking it up), REST (changes to collections) etc. Also some connectors imply higher level concepts such as response and request, message queues etc.
There is literally science about connectors.
IMHO, FFI is a abbreviation used in programming language design to specify the capability to invoke functions not specified by the ABI of the programming language (so the connector CPU/memory/in-process/same-os). If your perspective/abstraction is that you are a SaaS doing some external integration, this generic rest/http API surely feel like FFI but I would not kidnap a term used for language/runtime design.
Why the derail about Architecture: the words you search are in the science behind Architecture.