I am writing a simple web page for our existing web site that will only be used by the web site admin to delete all images from a certain directory on the server. He would browse to this page from his web browser (not to be consumed by any external services as of right now). I was thinking of creating another ASPX page (obviously not linked from or to anywhere) that implemented this. Is this considered a RESTful API? If not, what would be, and would it be a more elegant solution than what I'm proposing?
I realize this is an extremely simplistic example, but I'm trying to understand what RESTful really means and if it would benefit our existing infrastructure in any meaningful way, so that's kind of the purpose of this question.
Our website is written entirely in ASP.NET 2.0 WebForms.
It depends on your URL structure. a classic REST API call would be to, say:
/images/delete
You would then send a Post as DELETE or just GET or POST to this to do what you need. That's more the RESTful way. REST isn't so much what you are doing with the method as the structure of that method. I hope that makes sense :).
Related
I'm new in ASP.net MVC Single Page Application (SPA). I want to design a system that using SPA concepts.
However, I have a bit confusing on how a system consider design in SPA concept? Is it the system URL must always same although we perform many activities or don't have back function (browser) as it always in one page because only render the necessary HTML part? I did googling on this, still have no idea. Does anyone can explain in more simple way?
Thank you.
One of the main advantages of having an SPA is that because you only have one page and you load all the data at once (or make multiple AJAX calls in the background to get data on demand) your application gives an illusion that there is no post back to the server, making your web application seem like an app.
Using SPAs can potentially improve the user experience of your application.Site speed can be improved but you might have to make a user wait a few seconds to load all the initial data.SPA's are great for touch screen appications, such as kiosks and touch based Point Of Sale systems where the navigation is 100% controlled by the SPA.
SPAs also have a lot of disadvantages like implementing the back navigation in your site.In traditional websites this is not a problem but in an SPA you would need to make very clever use of javascript libraries such as Backbone.js or Angular.js to mimic this functionality.Also search engine functionality of public sites and analytics may be a problem.If your are writing a huge enterprise type of application, you may encounter performance problems.
I would stronly recommend reading Disadvantages of Single Page Applications before you make a decision on whether to use them or not.
A SPA can still have multiple different URLs.
In this case, the server that is hosting the application needs to be configured to direct all paths for a URL to the main index.html page.
The index.html page will load the initial part of the SPA, and if it sees there is a path on the URL beyond /, then it will load the "component" for that path.
A "component" as described here might consist of HTML, JavaScript, and request any data that is requested from external APIs.
Angular is a SPA framework that has built-in support for loading components based on registered URL paths. There are other SPA frameworks, as well.
I'm just starting to convert an existing ASP.NET Web Forms website to ASP.NET MVC. However, MVC seems excessive for some pages. ASP.NET Web Pages seems like a better fit for simple pages where the benefit of MVC is unclear.
If I use ASP.NET Web Pages for some pages and MVC for the rest, what difficulties will I likely encounter that would not occur if MVC was used for every page?
Here is one difficulty I am already aware of: Web Pages and MVC cannot share _Layout.cshtml.
EDIT
The content above was heavily edited to clarify the intent of the question.
I did a little research into this and now fully understand the scope of your question. Sorry, it was my mistake for thinking you mean Web Forms and not the relatively new Web Pages.
Any answer anyone gives here will be pretty subjective, but my take on this is to go ahead and stick to the MVC method instead of mixed modes. It appears that Web Pages is a razor based HTML file without a controller/action associated with it. If that is truly the only major difference / reason for your question, then it seems the extra three lines of code it would take to make it MVC...
public ActionResult StaticFile(){
return View();
}
actually will make it a) easier to add dynamic data to in the future, b) more directly ties into routing (no special routes for static for example) and c) easier to interact with the server-side if you have to do any kind of authentication, session tracking, etc, etc. Anyways, my 2 cents. Go the way that works, but keep in mind the trouble/frustration of future modifications as you go forth with your site. I post this opinion with the admission of never having used Web Pages, just a few hours of reading about them.
The biggest pain is the maintenance of a Master Page and a __Layout view. That being said I am with Tommy - why not just make these static pages html files and not aspx pages.
I decided to abandon ASP.NET Web Pages and use MVC exclusively on my website. The primary reason was because of the duplication of effort for things that could not be shared between Web Pages and MVC. Here are some things I learned.
Web Pages and MVC could not share _Layout pages. I was able to work around this by moving shared content into sub-layout files that the Web Page _Layout and MVC _Layout files could share.
Forms authentication was no problem.
I was not able to figure out how to implement MvcSiteMapProvider in the Web Pages for breadcrumb functionality. (See this question.)
The MvcSiteMapProvider difficulty made me realize that it was just a matter of time until I found something else that could not be easily shared. Therefore it seems smarter to stay with MVC rather than taking a hybrid approach.
Is it possible to post data from an asp.net application in one domain to another application on a different domain?
I've seen some of the posts where people mention some rather strange ways to inject forms into the response stream, but this seems overkill.
Is it possible and what is the best way to achieve it without hacking Asp.net to death?
Thanks,
Jacques
It's absolutely possible, and pretty easy to do.
Browser posts data to your .net app
Your app uses the HttpWebRequest object to post data to the 3rd party site
3rd party site gives data back to your app or simply accepts post.
Your app responds to the browser with whatever you need.
I have no idea why you would "inject forms into the response stream" or do anything funky like that. Perhaps you could add a bit more about your requirements.
Chris.
If you have access to both applications then the best way is to do it server side.
So make a web service available and consume it from the posting application.
or
Use httpwebrequest server side, see link below.
http://www.netomatix.com/httppostdata.aspx
On the client you could use a library such as http://easyxdm.net/wp/ - though there is a bit of a learning curve.
Here are a couple of links that may help you if you dont want to use the above routes and are prepared to edit your asp.net pages.
http://blog.dmbcllc.com/2009/11/11/asp-net-cross-domain-form-submission/
Cross-Domain Posting in ASP.Net loses Form Fields
I am trying to implement a service to download a image file. The code does nothing but upload a file to the response with each client request.
There are no SOAP messages involved but I am planning to implement it as ASP.NET web service. It can also be implement as ASP.NET website but since it has no view (forms, html etc) I planned to implement a web-service.
Is this a better approach? Does ASP.NET Website offer better performance that a Web-service?
Which one would be better is this situation?
I'd suggest using an ASHX handler. If you haven't heard of them before, you can think of them as a code-behind file without the ASPX view. Generally speaking they are considered more light weight than a web service.
Well first off, do you need code to handle the image request at all? Is the image processed in some way relative to the request, or is it static? Why do you want to implement this in code instead of simply serving a static image over http? Are there security considerations to be taken into account, e.g. serving images to particular users based on their credentials?
Unless you can give us a little more detail of your requirements it's impossible to make any concrete judgement or recommendation.
I am trying to create a static HTML page which has a <form> which posts to a 3rd-party ASP.NET website.
Is this possible when the target website uses ASP.NET webforms?
This is absolutely possible. You can issue a POST to any website, anywhere. (Keep this in mind when you're designing an application that accepts POSTs from a web merchant such as PayPal ;-) make sure you know where the POST is coming from.)
Whether or not the website will accept your request, of course, is up to however the server-side code was programmed. If you're POSTing to an ASP.NET WebForms app and the app wasn't designed to accept third-party POSTs, then you're going to have a hard time making your POST parameters look like they came fro ma WebForms page. For example, the website will be looking for the encrypted viewstate, among other things.
You could use firebug or some other tool to sniff the POST data from the webforms app, and then replicate that data in your static HTML page .... it might work.
Do you have any programming control over the ASP.NET Webforms app at all?
check out this question:
How to POST Data to another web application (cross domain)
Let me know, if you need help with my implementation.