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.
Related
I need to develop a web service to accept and save XML files transfered via POST requests. The chosen platform is IIS - problem is, I have zero experience handling ASP.net so far. While I think that handling the request object and saving it to the system should be easily doable, I am very insecure how to deal with the components of IIS itself.
AFAIK the source system (SAP) throws a POST directly at an URL, so I don't neccessarily need an actual form or page, but how do I weave it all together?
Do I still need a page or just a handler, how would I register it, to what extension?
I would be very happy if someone could give me a little jump start and point me in the right direction.
Thanks in advance,
Christian
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.
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 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 :).
I'm very new to the whole Ajax/Asp.Net stuff so...
I know that there are at least a few different ways of implementing the server-side of an Ajax enabled Asp.Net site.
One way is to add static methods to your aspx page's code-behind and mark them with the WebMethod attribute.
Another way is to use a separate ASMX web service file (which I don't know anything about :) ).
What are the most commonly used options for implementing the server-side? What advantages and drawbacks does each one have? And how does each one fare from a security and session perspective? (Making sure the server knows which session the Ajax request is from and ensuring only logged-in users are responded to?)
Typically I like to use jQuery to make the requests to .ashx page that is responsible for reading the data and passing back the JSON to the page to deal with. It sounds like the other options you suggested are pretty complicated by comparison.
The two most commonly used options are
Microsoft ASP.Net AJAX
JQuery partnered with webservices or request handlers (like Jon's answer)
Microsoft's ASP.Net AJAX is a framework that revolves around two server controls - the ScriptManager and the UpdatePanel. It's a bit more heavyweight than other options, but it's certainly a simple way of ajaxifying your site. You simply use an UpdatePanel to surround the portion of the page that you wish to be asynchronous, and all your controls that do postbacks (buttons, links, etc.) automatically become asynchronous requests that will only update that portion of the page. No coding or anything.
If you do plan on using the webservice route, ASMX is not the way to go - it's basically a "legacy" technology at this point and you should consider using WCF services instead.