Live data from Hacker News

Minimal APIs at a glance in .NET 6

hanselman.com

31–40 of 114 posts

Re: Minimal APIs at a glance in .NET 6

#31
post #27

It never takes long when throwing together toy examples with these kinds of APIs to introduce a security risk: var uploads = Path.Combine(uploadsPath, file.FileName); Where file.FileName appears to be drawn from the content-disposition header of the request. MS’s own asp.net docs on file uploads say: “Use a safe file name determined by the app. Don't use a file name provided by the user or the untrusted file name of…

> At least when the controllers are all classes I can unit test them. You can usually very easily transform lambas in function, so testing shouldn't be a problem.

Lambas, the famous Elvish mathbread?

Re: Minimal APIs at a glance in .NET 6

#32
post #8

The old convention based model for controllers, was really difficult to understand and debug. You never knew what routes exactly were discovered by reflection. It was just too much magic, and too many conventions. I hope this will make it easier. Reminds me of the good old Nancy times.

More importantly, if the default is to depend heavily on conventions, MS should have had a big glaring button / warning / notification in the Introduction page, which summarizes all the conventions used. Would have saved many beginners a lot of time.

I am an experienced programmer and was very frustrated having to search for all the conventions used in the framework.

Re: Minimal APIs at a glance in .NET 6

#33

It never takes long when throwing together toy examples with these kinds of APIs to introduce a security risk: var uploads = Path.Combine(uploadsPath, file.FileName); Where file.FileName appears to be drawn from the content-disposition header of the request. MS’s own asp.net docs on file uploads say: “Use a safe file name determined by the app. Don't use a file name provided by the user or the untrusted file name of…

> At least when the controllers are all classes I can unit test them.

I was always having great difficulty testing ASP.NET MVC controllers given the use of completely closed off, cyclical dependency, sealed class, properties like HttpContext.

Helper libraries made it somewhat easier to set them up but they were always heavy tests as a direct result of the large object graph needed.

Re: Minimal APIs at a glance in .NET 6

#34
On the one hand, I've been using approximately this style for defining routes for years using NancyFx. It's easy, it's explicit, it's much better than either the attribute or convention routing ASP MVC and WebApi have used.

On the other, I hate how this is telescoping all the configuration and setup code into a blackbox. Any kind of real project, even minimal microservices, is going to have to deal with authentication and caching and logging and monitoring middlewares, and it's bad that these samples obfuscate the way that one would do that.

Re: Minimal APIs at a glance in .NET 6

#36

Translation for non-web-people: how to write a minimal web service in dotNET. I probably missed when the acronym "API" was hijacked by the web people to describe a custom web service protocol.

Yeah, it's like 'front-end' by default means a bunch of js and html mashed together, rather than native UI.

Re: Minimal APIs at a glance in .NET 6

#37
post #11
post #2

So I guess we've had 'JavaScript but like C#', in the form of TypeScript; so I suppose now we get 'C# like JavaScript'? I must admit, I find this amusing. I suppose this raises two questions: "Why use C# like this in place of express or koa on node, which idiomatically similar?", and "Why use C# like this instead of C# like that (the way all other AspNetCore apps do it)?"

You still get C#/.NET, with it's superior performance and type safety, but just without all the OOP bloat.

Wait, you think this is not OOP?

    var app = WebApplication.Create(args);
 
    app.MapGet("/", () => "Hello World");
 
    app.Run();
You're creating an object and calling methods on it..

Re: Minimal APIs at a glance in .NET 6

#39
post #23

This is part of a larger push to make ASP.NET Core and .NET easier for beginners. The difference between node.js + express vs. ASP.NET Core was a lot of boilerplate to return the first Hello World. Overcoming that churn is a huge problem for .NET adoption. Do not take three-line-minimal APIs as the end product for robust, safe and reliable endpoints. We all know better than trusting 3-line-presentations. As a seasone…

When it is purely about ASP.NET, getting rid of the old style Startup class is ok for me.

The code is more compact, concise and less verbose. Most of the code in the startup is not touched in any meaningful sense after the initial setup.

Re: Minimal APIs at a glance in .NET 6

#40
post #33

It never takes long when throwing together toy examples with these kinds of APIs to introduce a security risk: var uploads = Path.Combine(uploadsPath, file.FileName); Where file.FileName appears to be drawn from the content-disposition header of the request. MS’s own asp.net docs on file uploads say: “Use a safe file name determined by the app. Don't use a file name provided by the user or the untrusted file name of…

> At least when the controllers are all classes I can unit test them. I was always having great difficulty testing ASP.NET MVC controllers given the use of completely closed off, cyclical dependency, sealed class, properties like HttpContext. Helper libraries made it somewhat easier to set them up but they were always heavy tests as a direct result of the large object graph needed.

But why? generally you don't test controllers directly.

You test "service"/"handler" classes that handle those requests.

If you want to test controllers, then you write E2E tests that send HTTP requests

Here's some example of how it might look like

https://docs.microsoft.com/en-us/aspnet/core/test/integratio...

Post reply on HN