MIKESTOWE.COM

you are here

Code on Demand… Today.

“Sometimes I feel that ‘over-engineering’ is this disease that is running wild in our industry and as architects we need to be on the constant watch to quickly eliminate it whenever encountered.” – Drew Jaegle, in response to API Best Practices: The Wrap Up

Last week Jason Harmon asked me if there were any good examples of code on demand APIs, to which I had to reply, “none that I know of.” The reason for this, I explained, is the difficulty we have in implementing code on demand, supporting multiple languages, security concerns, etc.

The other night I realized I too might be making things too complicated- as perhaps rather than trying to create a truly dynamic client – at least to begin with – we could instead create an interactive client that is capable of updating its field requirements and validation depending on the resource scenario.

Of course, this would be most beneficial when working with a client that has a user interface for its users (as fields could come and go), and isn’t perfect in itself. But what it could do is provide dynamic fields AND dynamic validation, enabling the client to validate requirements BEFORE sending requests to the server, and implement these different requirements when interacting with their user.

Perhaps the simplest method of doing this is the creation of a base validation class with generic methods, or a standard class the client would add to their architecture to be extended upon when making a code on demand call for form fields/ validation.

[gist id=”751ee06083de86ca49ce” file=”validator.php”]

The client would then, when making a call, acquire the dynamic code, evaluate it, having a newly instantiated class that extends the base validation class they have already installed (this reduces the amount of data being transferred). Of course, you would want version keys on the Validation Class and the code on demand as this would offer you the flexibility to pull down the full code on demand class including an updated Validation class (one time use only) while logging that the client needs to update their validation class (preventing security risks with write access).

[gist id=”751ee06083de86ca49ce” file=”implementation.php”]

The other challenge we have regarding code on demand is that no spec currently supports it. CPHL – which is based on HAL extends HAL’s capabilities to allow for code on demand – including critical information including whether or not it is record specific and if it is cacheable.

Theoretically, by utilizing CPHL (or another format that supports code on demand), you would be able to provide your clients with dynamic form fields depending on the call they are trying to make, as well as a way of validating the data on their end. Unlike Siren, this would let them gain access to the form fields and validation code before ever making a call to that resource (as it is referenced in the link structure) and allows the code to be cached (if cacheable) reducing the data being transferred with each call.

[gist id=”751ee06083de86ca49ce” file=”cphl.json”]

Of course, at this time, this theory remains untested. However, last night I started playing and loosely throwing together a sample Validation class in PHP – and as such hope to be able to start testing it here shortly.

The biggest challenge that remains is how to condense the different code versions into a singular format to reduce rework on the server end (imagine returning something like JSON that could be parsed into PHP, .NET, C#, Java, Python, etc). This would also help eliminate the security threat of evaluating the passed code (unless the validation library was out of date, in which case we would still need to pull the full class and evaluate it).

Assuming one is only passing back simple form fields and validations, I cannot imagine this would be too difficult, as the client could quickly deserialize the data and transform them into arrays/ objects that could be utilized by the validation class.

However, whether or not that is the right way to go remains to be seen. But in the most simple formats – for APIs who have struggled with unique rules within their systems, code on demand may not only be a possible solution, but the best solution. A solution that is available today, and one that will potentially change the way we interact with APIs in the future.

Share this Page:
Facebook Twitter Linkedin Reddit Tumblr Email

Leave a Reply

Your email address will not be published. Required fields are marked *