At last we’ve come to the last of my planned scenarios for this prototype–a little thing I like to think of as a WYSIWYG Web Service, or WYSIWYGWS for short. A few months back I had recently finished the JSON literals post and video and was anxiously combing my immediate vicinity for more scenarios when Scott Hanselman came along quite serendipitously with his post, Converting an Excel Worksheet into a JSON document with C# and .NET Core and ExcelDataReader to inspired me.
I asked myself “How simple can defining a REST endpoint be?” and here is the result.
Of course there are myriad ways to approach this problem with various trade-offs, this is just one.
One developer on Twitter asked Scott (paraphrasing) “Why not just use PowerShell?”
To which Scott replies, “Very useful, yes, but would require additional PowerShell to get the output JSON I wanted”
And another developer says, what are the benefits of using ExcelDataReader over this PowerShell command?
And Scott reiterates, “Control over the result is all”
And that’s one key aspect to this scenario. Scott had an idea of what shape he wanted at the end and it was just a matter of getting what he had into that shape. And in the video above that’s exactly how I approach the problem as well, I start with that shape and then populate it. Now that’s what I call… Design by Contract! (ba dum chhh)
Another element to the scenario is data that is… uncooperative:
- You can’t control it
- You can’t annotate it serialization attributes
- The shape isn’t right for default serialization
- It’s coming directly from an external (not .NET objects) data source like a database, mainframe, device, other service, or in this case a file
And that last point is more important than you might think. Every day (on Facebook) I see a lot of developers working on apps that use DataSets as their data layer and/or are using an RDBMS that doesn’t have SQL Server’s fancy `FOR JSON` clause. Without getting into a big argument about whether those folk need to “Get with the times” and “Move everything over to X”, what’s the fastest way for them to Cloud- or Mobile-enable that data? And even if you do have POCOs for your domain-objects, there are a lot of reports in life and not every report deserves its own custom EndOfYearSalesByRegionReportRecordRow class just so you can use JSON serialization.
It’s also just a useful way and crazy easy way to mock up an service end-point. When I was exploring the GitHub Gist API I was very conscious of how my debugging might look to the GitHub service. Was I hitting the live API up too much? Will I hit a request limit? With this I can just go to a service, grab the output, and paste it and develop against that until I’m ready to hit the live service. Ease in testing is its own reward.
Conclusion
In my last post I combined top-level expressions with XML literals to create a basic VB.NET view engine for web pages on ASP.NET Core. In this post I took the same strategy but swapped out XML for JSON literals to make ASP.NET Core REST services a breeze in VB.NET. The approach has trade-offs and shines especially when dealing with one-off data sources such as files, database reports, and objects you can’t modify for serialization but yet still need to end up in a particular shape in the end, as well as testing.
So what about you?
Do you have any data you need to get out of some less that reputable places as painlessly as possible?
Does the low-ceremony abstraction I presented seem like the kind of thing that would make that easier or more attractive for you? Let me know in the comments below, or on Twitter.
Thanks for your time, your shares, and your feedback!
Regards,
-ADG
P.S. This is the last scenario 😥 in this series so my next post will be letting you know that the write-up of my design notes from exploring this idea have been posted on GitHub. Thanks for your patience!
Anthony's blog 