We found BIF designers considering RPC vs REST. Referencing this API design document from Apigee, now part of Google Cloud page
> The three primary ways to use HTTP for APIs > Most public APIs and many private distributed APIs use HTTP as the transport, at least in part because organizations are accustomed to dealing with the security issues of allowing HTTP traffic on ports 80 and 443. > In my opinion there are three significant and distinct approaches for building APIs that use HTTP. They are: >-REST >-gRPC (and Apache Thrift and others) >-OpenAPI (and its competitors).
RPC vs REST is important now because there is a gap between traditional web/mobile applications and blockchain applications (web 2.0 and 3.0 if you will).
> Authentication protocols in the sense that blockchain networks rely on private keys belonging to a Public Key Infrastructure (PKI) to authenticate users while traditional web/mobile applications mostly rely on a centralized authority storing hashed passwords and the issuance of ephemeral tokens upon successful authentication (e.g. successful login with a password).
> Traditional (Web 2.0) applications (that adhering security best practices) use server-side sessions (web) or secure keychains provided by the operating system (iOS, Android, etc.) The current industry standard and state of the art authentication protocol in the enterprise application development industry is Open ID Connect (OIDC). paper
HL BIF now Cactus
We have have other security considerations.
Swith to @grpc/grpc-js to avoid native code PR
Consider the following plugin based architecture.
Native plugins in network computing, will fail (sometimes) on storage reclamation, i.e., they have fatal use-after-free bugs. This will make plugins an easy attack vector. Now we know why Wiki implemented Caja for plugins.
YOUTUBE MHfeyH8aiE8 Why be uncertain about security...
Standardized way of defining and (automatically) documenting the REST API through the OpenAPI specification: Swagger IO specification page
BIF whitepaper PR123