I have a client that's converting from a PHP system to a .NET system. One requirement is that certain legacy system URLs ending in ".php" are still accessible in the new .NET environment.
Essentially I need to map arbitrary string paths to specific Controllers/Actions.
Can anyone tell me what the recommended and most performant approach is in ASP.NET Core 2.0 to handle this scenario? Custom middleware? Introduce a Web.Config? Action attributes in the controller?
Are there any "gotchas" I should be on the lookout for?
The site is hosted in Azure, if that makes a difference.
Thanks in advance!
Can anyone tell me what the recommended and most performant approach is in ASP.NET Core 2.0 to handle this scenario? Custom middleware? Introduce a Web.Config? Action attributes in the controller?
I assume that you could leverage URL Rewrite and read the related tutorials. I just checked it and added the URL rewrite rule under my azure web app via the Azure App Service Editor as follows:
TEST:
Additionally, you could also write the URL rewrite rules in your code, details you could follow URL Rewriting Middleware in ASP.NET Core.
Related
I need to iterate through the nodes in Umbraco 6.2 in the external web application.
But dont know how to make a connection in the code behind to Umbrao cms.
Thanks
Easiest way would be to use umbraco web api.
Umbraco Web api would allow you to set up a restful web service that would call via a url with querystring parameters if required.
In the web api controller, you would have access to all of the Umbraco nodes and you could return results in xml or json format as required.
This is a good reference - https://our.umbraco.org/documentation/Reference/WebApi/
Wing
I'm looking to make a RESTful API on ASP.NET for a website. My problem is that I need it to be integrated into the website and not as a separate project.
I understand that WCF makes this really easy and its the ideal way to do it, but I don't think you can combine a WCF Service Project and a ASP.Net Website, Is this correct?
Is there a way we can do this using a webservice (asmx) file (since I know that asmx services use SOAP no?)
The reason I need this to be in the same project is that the customer will be able to purchase ssl for their domain (which the website is going to use) and I need to make the API secure as well, but the customer should not be asked to purchase two ssl or even a wildcard one.
Knowing this, is there a better easier way of doing this using WCF?
Take a look at the new MVC4 Beta, it's set to go live sometime between March and April this year and should be able to accommodate your requirement to build a RESTful web service alongside a web application. I haven't spent too much time with MVC4 to go into the details, but it's definitely worth a look. Links: Get MVC4; MVC4 and WebAPI blog.
Hope this helps!
You can use ASPNET MVC to build an API along with your website.
See How can I implement a site with ASP.NET MVC without using Visual Studio? for some details on building a basic MVC site.
ASPNET MVC services can respond in JSON or XML, or both.
There will be no special requirement for two SSL certs.
I have an ASP.NET MVC 3 application that exposes both WCF REST services. I'm using .NET 4. You'll have to pay attention to how you configure your routing. For example, my WCF services are prefixed with something like "api/v1/" while all other requests are handled by ASP.NET MVC 3.
I had a problem because IIS refused to serve some "localhost" requests (like when your MVC 3 controllers try to consume your WCF rest services). That was solved by adding an entry to my hosts file. Also be aware of this when implementing an OAuth 2.0 Resource Server or Authorization Server.
Using WCF for REST services works ok in .NET 4, but the JSON serialization sucks big time. There are issues with default dates and it is rather slow. You may want to look at using a different serializer. With WCF you sacrifice some flexibility for some features you get for free.
ASP.NET MVC 4 (and the WEBAPI) is still in BETA, so I'd avoid that for a project with a short term release date.
I'd actually use NancyFX. Setting up routes is super-easy, and it comes with built in XML and JSON serializers that act based on the data in the headers.
I'm just wondering, if you are creating a new ASP.NET web forms app in ASP.NET 3.5, which would you recommend for URL rewriting? UrlRewriter.NET or ASP.NET MVC Routing. I've used UrlRewriter.NET before and was pretty happy with it.
Opinions anyone?
Routing is vastly superior IMHO. Rather than faking it (rewriting urls to keep the SEO types happy) you are making it (making real urls to keep the SEO types happy). The other huge advantage is that routing is reversable--you can easily get the URL from the parameters, which comes in very handy.
No, they do vastly different things. The url rewriting takes an incoming url and rewrites it before passing the request off to ASP.NET (or IIS) to handle. Url routing takes a url in ASP.NET and maps a handler using parameters found within the Url. The Url itself is never changed.
Use UrlRewriter.NET - it was built for web forms and you already have experience with it and like it. ASP.NET MVC routing is designed to work within the MVC pattern.
If you are using IIS7, go with the URL Rewrite Module.
I used it for one of my sites, and it worked perfectly.
Why not just go with Asp.Net MVC and ditch the webform methodology altogether? I realize that the framework isn't for everybody, especially for pre-existing projects, but if you are starting to develop a new app and are shopping for a routing mechanism, why not go for the framework that is built upon the notion?
Asp.Net MVC is a vastly superior framework over WebForms, it just requires a bit more upfront work and has a learning curve. At the end of the day though, you'll generally end up with an application that is much easier to expand and maintain.
ASP.NET 4.0 web forms (I believe that it was introduced in 3.5 SP1) has routing build in natively. It has the benefit over rewriting modules that it is build in natively in the ASP.NET frameworks, and therefore does not need hacks to work correctly.
So you shouldn't go for MVC just because of the routing.
We currently have a classic ASP.NET web application which serves as our API. It basically has a bunch of ASMX Web Services, but these are really cumbersome to work with from JavaScript. What I want is to expose a set of RESTful endpoints, but doing this in classis ASP.NET is not what I really want to do.
I'm considering to combine both classic ASP.NET and ASP.NET MVC in one web app. Is this possible at all? If yes, what are the issues/problems I may encounter?
Aha! It seems that this is very much possible. Here's a comprehensive article which describes what should be done.
An ASP.NET Webforms application can become ASP.NET MVC enabled by following some simple steps,its quite easy infact see this link
if you want to go rest for mvc heres a article Rest for mvc by Phil Haack and Rest like nature of MVC heres a comparison Rest in asp net vs wcf
The whole goal of routing is to break
the one-to-one association between
URLs and files in the server’s file
system. However, the routing system
still does check the file system to
see if an incoming URL happens to
match a file or disk, and if so,
routing ignores the request (bypassing
any route entries that the URL might
also match) so that the file will be
served directly.
So, to answer on a part of your question "is this possible at all": Yes, because routing system will recognize the .asmx file on the file system and it will process it in classic asp.net web services manner.
For the second question I'm not sure because I haven't been doing anything complex with web service inside of the asp.net mvc application.
In a recent project, I built my own MVC framework in PHP. One of the things I implemented was a routing system. I used Apache's mod_rewrite to send all requests to index.php, and then parsed the URI to extract information and route the request.
I'm dabbling in ASP.NET now, and I'm wondering if/how I might perform something similar. Is there a way to route all requests (similar to the way WordPress does it) to one page where central route processing is performed? I'm aware of the MVC framework for ASP.NET, but I'd like to take a stab at this myself as I'm tinkering around and learning.
EDIT:
BTW, my hosting provider runs IIS 6
This is going to be a long answer, because I want to make sure you are fully aware of all the ways you can accomplish what you want to do.
The routing engine that powers the ASP.NET MVC Framework will work with the traditional ASP.NET Framework. You can take advantage of using the RouteTable and assigning routes, just like you would in an ASP.NET MVC application. You just don't get the MVC portion in traditional ASP.NET sites. That was a huge enhancement for the ASP.NET Framework and it was great to see them reuse that code and make it work in both frameworks. If you want to learn more about this, check out ScottGu's post and scroll down to URL Routing Improvements. Also here is a reference on how to use the System.Web.Routing in WebForms by Phil Haack.
Now, if you still want to write you own. You will need to learn the ASP.NET HTTP pipeline and how to implement the IHttpModule and the IHttpHandler interfaces to create your own HttpModule or HttpHandler class to handle your routing. These interfaces are the key in writing your own routing engine. To help put those interfaces in a working example, I couldn't recommend this MSDN article enough. It shows you how to with either interface and explains the differences when creating your own routing/url rewriting engine.
Now, if you find out that this might be to much for you. There are third party libraries you can use of people who already wrote a routing/url rewriting engine in .NET. Here is a question that I saw not to long ago asking "What Url rewriter do you use for ASP.Net?" right here on SO.