DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Implementing Effective Document Fraud Detection in C#
  • A Guide for Deploying .NET 10 Applications Using Docker's New Workflow
  • Formae and PKL: Revolutionizing Infrastructure Automation
  • Pulumi: Modern Infrastructure as Code With Real Programming Languages

Trending

  • A Deep Dive into Tracing Agentic Workflows (Part 2)
  • Persistent Memory for AI Agents Using LangChain's Deep Agents
  • Prompt Injection Is Real, So I Built a Python Firewall for LLM Pipelines
  • Is the Data Warehouse Dead? 3 Patterns From Enterprise Architecture That Answer This Question
  1. DZone
  2. Coding
  3. Languages
  4. Dynamically resolving URLs in .Net 5

Dynamically resolving URLs in .Net 5

Should you choose a static programming language or a dynamic runtime? And why is Winnie the Pooh relevant to the answer to that question?

By 
Thomas Hansen user avatar
Thomas Hansen
DZone Core CORE ·
Apr. 09, 21 · Tutorial
Likes (2)
Comment
Save
Tweet
Share
7.0K Views

Join the DZone community and get the full member experience.

Join For Free

My favourite feature with .Net and C# is that it's a static programming language. This is also the largest problem I have with .Net 5 - As in, its blessing also becomes its curse. Simply because sometime I need a bit more "dynamic nature" than that which .Net provides out of the box. However, .Net 5 has a lot of interesting features, allowing you to circumvent this, opening it up for a more "dynamic nature". Let me illustrate with an example C# HTTP API controller.

C#
 




x
9
10


 
1
[Route("magic")]
2
public class EndpointController : ControllerBase
3
{
4
    [HttpGet]
5
    [Route("{*url}")]
6
    public async Task<ActionResult> Get(string url)
7
    {
8
        /* Do interesting stuff with URL here */
9
    }
10
}


Notice the [Route("{*url}")] parts in the above code? This tiny little detail implies that everything going towards "magic/xxx" will be resolved by the controller, and its "xxx" parts will end up becoming the url argument to our method.

This tiny little trick allows you to create a dynamic controller, that resolves everything, within a root URL, where the URL itself becomes an argument to your method. This was what I hinted towards in my previous article when I said "now all you need to do is a way to dynamically invoke endpoints". You can see the entire code in my magic.endpoint project, specifically in its EndpointController class. The MagicEndpoint controller class in Magic, basically resolves all the 5 most commonly used verbs in this way.

  • GET
  • POST
  • PUT
  • DELETE
  • PATCH

All the methods in this controller, takes the URL dynamically, where the relative URL becomes an argument to its method. This allows me to dynamically load my Hyperlambda files, and execute them as such. All in all quite brilliant if I may be so courageous as to say so myself in fact :)

Using tiny little tricks as this, I am able to take something that is fundamentally static in nature, turning it completely on its head, making it 100% dynamic. This allows me from a use case basis to choose which paradigm I want to use for each individual problem I face. If I need static typing, I use normal C#. If I need a more dynamic runtime, I choose Hyperlambda. And both paradigms perfectly aligns with each other, allowing me to interoperate between everything with a simple signal invocation.

  • 100% dynamic platform - Check!
  • 100% static typing - Check!

It's almost as if you can hear Winnie the Pooh in the background answering "Yes please both" to the question of whether or not he wants chocolate or honey. Basically, once confronted with the question of "do you want static typing or a dynamic runtime", your knee jerk reaction should be as follows ...

Yes please, both!

The above little trick, allows you to use .Net API controller endpoints to literally execute any dynamic scripting language you need, where the URLs resolves to the script files on your server's file system. Of course, Magic only executes Hyperlambda files, but you can just as easily execute Lizzie files, Python files, or Ruby files for that matter - As long as it is an interpreted language of some sort. In fact, I am not sure if I would recommend it, but you could probably also resolve your HTTP invocations directly to SQL files using this little trick.

Below you can find a link to download Magic and try out the whole platform tying all of these constructs together if you wish.

  • Download Magic
C Language .NET programming langauge

Opinions expressed by DZone contributors are their own.

Related

  • Implementing Effective Document Fraud Detection in C#
  • A Guide for Deploying .NET 10 Applications Using Docker's New Workflow
  • Formae and PKL: Revolutionizing Infrastructure Automation
  • Pulumi: Modern Infrastructure as Code With Real Programming Languages

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook