I am looking for guidance on how to start building a http REST server using C# and a SQL Server database?
Is there a recommended server framework for http web server? The same for REST services?
How should I start? Raising regular server and after that taking care of the SQL Server database?
Thanks.
I'm starting to evaluate REST frameworks for .Net and python. So far I like ServiceStack for .Net the best. It's simple, far easier to config than WCF, supports dependency injection, and seems to be fast.
When VS 11 and .Net 4.5 are completely released, Microsoft is also offering Web API. It can be used to build REST API's as well so it's worth looking into.
I haven't done enough research on Web API to see which would be better but those are some considerations for you.
Use OData. Have a look at Creating an OData API for StackOverflow including XML and JSON in 30 minutes
Consider using the new ASP.NET Web API:
ASP.NET Web API is a framework that makes it easy to build HTTP services . . . ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.
It is currently in beta but was built specifically for building RESTful HTTP services in .NET, unlike WCF. See SO question WCF vs ASP.NET Web API for more details.
There are samples and video tutorials, and in one they are using Entity Framework models which can be backed by SQL. This SO question specifically covers that example: How to mix Entity Framework with Web API
Related
I'm new to ASP.Net and I have the following scenario:
I have a .Net Framework project folder with several projects. All of them are configured .Net Framework 4.7.2 and I have a dependency I can not change at the moment. So migrating to .Net Core is not an option at the moment.
My question is the following:
What is the correct approach to add the functionality of a RESTful server with ASP.Net?
I don't want to implement a frontend. I just want to add a server to my projects.
In
https://learn.microsoft.com/en-us/dotnet/standard/choosing-core-framework-server
it says, "In most cases, you don't need to migrate your existing applications to .NET 5. Instead, a recommended approach is to use .NET 5 as you extend an existing application, such as writing a new web service in ASP.NET Core."
How should I do that?
I'm really confused. Please help me.
Maybe some hints or links to other pages are enough to lead me into the right direction :)
Kind regards
Chris
It basically depends on your future preference and time, If the organisation is pretty much aligned with .netcore what you can do is you can easily migrate .net framework project to .Net standard and create a new .Net core project with API endpoints defined and you can easily refer the .Net standard libraries directly to it.
https://learn.microsoft.com/en-us/dotnet/core/porting/
But if you want to stick to .Net framework libraries, you can create basic Asp.Net core web API with DotNetframework, It is not a legacy framework, it has the latest release within 3 months and it is also battle-tested, But you can only host in windows machines unlike .Net core which you can host in windows/linux
https://developer.okta.com/blog/2018/07/27/build-crud-app-in-aspnet-framework-webapi-and-angular
any .net project that running on a web server supports REST calls. In fact if you make a webmethod?
Say this code:
<WebMethod()>
Public Function HelloWorld() As String
If keyid <> 123 Then Exit Function
Return "Hello World from server"
End Function
Then right out of the box with ONLY the above code?
The above supports SOAP 1.1, 1.2, and post (REST) calls.
So there is no "concept" in asp.net that you "adopt" SOME kind of RESTful server - the server you use in this case is IIS, and it supports REST calls out of the box, and always did from day one to my knowledge. You MOST certainly have to run a web server, but making REST calls does not require a "special" RESTful server, but just in fact that you running a web server - in this case IIS or so called internet services.
If you already have a project that supports and API just add an additional controller, assuming the functionality is not closely related to existing functionality.
I am learning about Blazor server apps. We have an existing asp.net MVC application that communicates with a WCF service via netTcpBindings. We are now thinking about moving our development into .net Core so based on that Blazor Server seems very cool to start with.
My question is, how can I consume the existing WCF netTcpBindings service on any new Blazor Server application? I have tried googling this but could not find much on the subject. Is it even possible to consume a WCF service in .Net core (because from what it seems WCF is not brought into .Net core)?
It is still possible to consume WCF from a .Net Core application. Bear in mind that it is nothing else than a communication protocol, so it doesn't really matter what "language" you are using as long as you are able to connect to the server providing the service and you implement the protocol.
Luckily the Microsoft people have that in .Net Core so
Say you have the following service:
on your Server on the Startup.cs file you can then do something like this:
Done, you may now invoke your WCF service from your .Net Core server
I'm trying to use client-side Blazor to display some data, provided by existing WCF service. I was able to add a connected service reference, the proxy is generated. But when I'm trying to invoke it like this:
var client = new SoftConServiceClient();
await client.PingAsync(new PingRequest());
there is a bunch of errors, related to MonoTouch. By digging into the code of Mono, there is an explicit NotImplementedException in the constructor of the System.ServiceModel.DnsEndpointIdentity.
Am I right to assume that there is no way now to call legacy WCF service from Blazor client-side? If that's not the case, can anyone share a guide about how to properly do it?
Bonus question: if that is not possible, what would be the best option to approach this? Modify WCF to become REST-ish or just drop it and implement .net core api service?
Thanks a lot in advance!
Core does not support WCF very well instead of not at all. Especially in terms of authentication and security, such as the service created by using WS* binding. But for services created by using BasicHttpBinding or Restful styles services. We could invoke them normally on Core-based clients, whether using client proxy class or Channel Factory.
Please refer to below official repository.
https://github.com/dotnet/wcf
I suggest you re-construct your server project with BasicHttpBinding or using Asp.net WebAPI to create the backend service.
https://learn.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
Feel free to let me know if there is anything I can help with.
WCF is not supported in .NET Core out of the box, however there seems like there is a community project that is working on adding support for it in .NET Core
https://github.com/CoreWCF/CoreWCF
See What replaces WCF in .Net Core? for more info.
Am I right to assume that there is no way now to call legacy WCF
service from Blazor client-side?
Yes, you're right... WCF is not supported in Blazor client-side, and it won't be supported in the future. Microsoft has decided to stop supporting it as from .Net 5.0, and suggest to use Web Api instead.
Depending on how much you are invested in WCF, you may shift to Web API, perhaps gRPC, or go on using WCF, hoping that the efforts of the community to port and support WCF might succeed.
I was able to to put WCF 4.7.2 using techniques found with SoftCore in .Net 5.
I can also work SoftCore Hosted Example Blazor Server.
I've done a bit of work in the past using WCF WebAPI and really liked a lot of its features, I'm just playing with ASP.NET Web API at the moment and it seems completely different (IE completely removed from WCF).
Does anyone know which features of WCF WebAPI are included in ASP.NET 4 Web API?
Ive done a little more reading around this and found a few pages by MS people on this:
http://wcf.codeplex.com/wikipage?title=How%20to%20Migrate%20from%20WCF%20Web%20API%20to%20ASP.NET%20Web%20API :
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web API -> ASP.NET Web API
Service -> Web API controller
Operation -> Action
Service contract -> Not applicable
Endpoint -> Not applicable
URI templates -> ASP.NET Routing
Message handlers -> Same
Formatters -> Same
Operation handlers -> Filters, model binders
and http://wcf.codeplex.com/discussions/319671
The integrated stack supports the following features:
Modern HTTP programming model
Full support for ASP.NET Routing
Content negotiation and custom formatters
Model binding and validation
Filters
Query composition
Easy to unit test
Improved Inversion of Control (IoC) via DependencyResolver
Code-based configuration
Self-host
From what I've learned, Microsoft did a little bit of naming confusion here.
I'm assuming you know what WCF is all about, this big framework built on top of XML to allow user to build distributed services with a wide variety of technologies (from SOAP to REST to MSMQ etc.).
It's hard as hell to use (for me at least) and requires a lot of bootstrap to have it working, and eventually they realized this and started providing some default configuration for simple http services (WCF REST starter kit anyone?). ASP.NET MVC was gaining momentum and some of the features it provided (automatic arguments matching for example) started to show up in WCF.
Now that's the situation:
Announcement: WCF Web API is now ASP.NET Web API! ASP.NET Web API
released with ASP.NET MVC 4 Beta. The WCF Web API and WCF support for
jQuery content on this site wll removed by the end of 2012.
http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
And that's better imho.
I'm quite sure it should be possible to host asp.net mvc4 webapi on top of WCF (if you ever need that), but i can't find documentation that can prove me right (or wrong).
UPDATE (can't fit as comment):
Wait, there is a huge different between "moving a subset of communication technology from a library/framework to another" and "replace WCF". I personally think that WCF was designed for some kind of communication concept and it has a rather cool design, but the distributed computing is somewhat moving on to new (and simpler) solutions (look the feature-rich SOAP vs the lean e flexible REST, although many people still use REST in a RPC manner), and i think that this kind of programming patterns better fit into the MVC architecture than the WCF one. Effort was put on designing some simple way of building/consuming web services on top of WCF, but they eventually found out that it was not the right solution.
Not to mention that many developers now use ASP.NET MVC and want to do rest web services for their web app, messing with WCF is often overkill for these kind of things, and I've experienced that on my own skin.
I think that the routing mechanism is awesome and the right way to go, and if you look closely, they included part of it (with different names and types, but the pattern was there) in WCF. So yeah, i think that if MS don't dismiss that part of WCF WE should do it. To strictly answer, no, i don't think you'll ever find WebGet/WebInvoke in asp.net mvc*, it just don't fit in.
Yeah self-host is probably the only bit of WCF contained in ASP.NET MVC4 right now.
It looks like WCF itself is somehow dying or at least becoming much less important then it was supposed to be and because of that it also has much less development effort put into its feature set. New features in WCF itself are more cosmetic.
WCF was designed as transport / protocol independent way for inter process communication. Even the idea was independent abstraction it was mostly build on top of SOAP stack. When WCF 3.5 brought support for REST it was mostly hacked in because REST is all about transport dependency. Using transport independent API to support inter process communication which is done through directly using transport features appeared inconvenient. As result MS first released WCF Rest API Starter Kit which never reached RTM but it was preview of features which was later included in WCF 4 and finally in .NET 4.5 or WCF Web API. Because REST is transport dependent and currently used only with HTTP (even it is theoretically possible to use other transport protocol) the API was moved to .NET part which is more suitable for HTTP processing - to currently very popular ASP.NET MVC.
WCF Web API is replaced by ASP.NET Web API which takes features from WCF Web API and merges them with the features from ASPNet MVC. ASP.NET Web API is a new (02/2012) framework for building and consuming HTTP services and a platform for building RESTful service.
Although not in the original question it seems worth noting that WCF is alive and well and its REST support remains useful when you have existing SOAP (WS-*) services you must support but want to add REST to reach more clients.
Reference
CodePlex: WCF Web API is now ASP.NET Web API
CodePlex: Daniel Roth on the Future of WCF
Chanel9: Dan Roth on the new ASP.NET Web API
The following excerpt found on this MSDN page summarizes this dilemma well.
Use WCF to create reliable, secure web services that accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.
Here is good article on Web Service, WCF and Web API http://goo.gl/T29A5B
Web Service
Based on SOAP and return XML Data
Support only HTTP protocol. It support only HTTP protocol.
Consumed by client that able to understand xml SOAP Services.
Can host on IIS. It can be hosted only on IIS.
Easy to Learn and understand.
WCF
Based on SOAP and return XML Data. SOAP is heavy compare then JSON and its overhead over network also.
Enhanced version of web services support multiple protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ via configuration.
More reliable when both client and server have .Net.
Its implementation and configuration is complex
Consumed by client that able to understand xml SOAP Services.
Self-hosting, IIS and using windows services.
Web API (Web API 2.0)
Design specifically for building HTTP Restful Services on .Net Framework.
Web API easily readable and handy as JSON.
Support all features of HTTP Like URls, Request/Response, Headers, Caching and Versioning.
Web API support many HTTP Verbs like GET, POST, PUT, DELETE etc.
Web API is stateless.
Web API supports MVC features (controllers, action results, routing, filter, model binders, IOC container or dependency injection)
Web API can be self-hosted, hosted with in the application and on IIS.
OWIN (Open Web Interface for .NET) is used for self-Hosting.
ASP.net web api is lightweight and REST support inbuilt. It is more suitable for mobile applications.WCF is bloated with more options . It depends on the complexity of the system to select one of these.
Where to get started if I want to design a web service with RESTFul API? Any built-in support from .Net Framework or any 3rd party tool recommend?
If your service is going to expose an information from a database, it's very simple to implement OData RESTful service (aka WCD Data Service) using WCF and Entity Framework.
Have a look at this blog post by Scot Hanselman. He shows how you can create an OData service for StackOverflow.
I absolutely love OpenRasta!
I tried the REST support in WCF and was quickly turned off from it.
Good luck!