Join the DZone community and get the full member experience.
Normally when we create an HTTP REST endpoint, we add code to our server endpoint, …
Join the DZone community and get the full member experience. Normally when we create an HTTP REST endpoint, we add code to our server endpoint, and assume the client provides the arguments to our code. What if we could reverse this responsibility, such that the client provides the code the server executes? Among other things, this implies we can have one endpoint doing „everything“. We wouldn’t need to create dozens of endpoints to expose our API, and we could get away with creating a single endpoint, that clients invokes, regardless of what they want to do. If the client wants to create a record in our database, read records from our database, or count records in our database is irrelevant – He’d still use the same endpoint for all of these tasks. In addition, the client could become much more creative in regards to how he interacts with our API, and do things we couldn’t even imagine as we created our API. The latter of course sums up the problem, which is that clients could inject malicious code into our server. Securing your lambda functions However, if we had a method to make sure the client was never able to inject malicious code into our endpoint, we could safely allow him to inject code and execute his code on our server, even without knowing what his code does, or even caring about who the client is for that matter. The latter is actually possible in Hyperlambda due to a feature I just released yesterday called „whitelist“.
