When I talk to an developer from the Microsoft ASP.NET world and he uses the word "Webservice", does that word in every case imply a specific data format (XML? SOAP?)?
Or is it just anything you can call via http(s)?
In my view, it can be anything that's over http/https, and intended for calling by an application rather than a user's browser.
In particular, REST and SOAP are quite different about how they pass arguments in and get results back
The term Webservice itself is language-agnostic.
This is a decent overview.
If an Asp.Net developer says WebService, you can pretty much bet that they are talking about XML/SOAP.
However this is not universally true. I think it's just fine to call anything a WebService if 1) the data source is available via the web or 2) it is a web address that can provide back information given a set of inputs.
For example, StackOverflow.com allows for screen scraping of the User pages in order for 3rd party applications to be built. It's not specifically XML/SOAP but I would consider it a Web Service (format #1)
In my experience this completly depends upon who you are talking to. For some ASP.Net developers this is only SOAP for others it includes other things like REST. If you are planning on using the term in a specification it would be a good idea to be a bit more specific.
I can only agree with Paul, anything queried over the web, using the http(s) protocol and not browser oriented. But any web service should also have the functionality of being discovered (WDSL and so on).
Personally I mean any HTTPHandler!
That means under ASP.NET, a page is a webservice that returns HTML.
WCF extends that concept, because by default, WCF service requests in ASP.NET are processed by Modules not Handlers.
So really any web request is a service.
Typically though ASP.NET developers will be refering to SOAP unless they prefix i.e. WCF Webservices,
Related
I have some internal-facing ASP.NET web services that have had numerous API additions over the years. Some of the original web methods, while still available for consumption, have recommended replacements available. I would like to steer consuming clients toward using these new methods so I can retire and eventually remove their elders.
If this were a client API rather than a web service API, I'd just mark the offending methods with the obsolete attribute. But .NET attributes do not get serialized and are not visible to consuming developers when they add or refresh web references.
What techniques are recomended for obsoleting ASP.NET web methods? Is there anything built into the tooling (VS2005-2010)? I don't want to break any of the existing clients, so I can't simply remove the web methods outright or change their internal behavior to reprot their usage as erroneous.
Tim, the short answer to this is unfortunately that you have to contact those clients and communicate the change with them and agree on timelines etc. There might be something that you can do to smooth the process over for them, particularly if they are not IT savvy clients and had to get their applications built by external contractors.
You can butter this up any way you like for them really, from the system is going to be replaced, to we are doing it bigger, better and faster.
Additionally you can build in code to slow them down, NOT RECOMMENDED, but then when they inquire you can give them the, we don't support that system any longer, it has been replaced by system 'X'.
If the new methods you are talking about are still just web-methods, you can just point the old ones to the new ones, and let the clients use the old one.
Another option is to identify the clients stuck on the old methods, get their IP addresses and lock it down so only they can use it, this way you ensure new clients will not attempt to connect to the old methods.
Other than that, I cannot think of anything that will not be a pain or difficult for both yo and the client.
I have a small RIA that I built as a learning/make-my-life-easier project that uses Flex and ASP.Net. Currently, my architecture utilizes straight HTTP posts and the server responds with xml. I posted another question about security in my web app and some people mentioned SOAP. SOAP is something I've never actually used and I was wondering what the pros/cons were to using SOAP over my current architecture and then subsequently, how much work is require to convert such an application to utilize SOAP.
Thanks,
Chris
Since you have already implemented your own message schemas for sending and receiving, then SOAP in of itself will not give you any added value. The added value comes from SOAP's support for the WS-* standards, covering security, transactions, and several other goodies. The recommended way to take advantage of all that is to use WCF rather than ASP.NET, because WCF supports the latest versions of those standards.
FYI when trying to use SOAP with FLEX - XMLDecoder in Flex does not currently decode some complex data types appropriately, making it appear that you are not receiving all data. I have tracked the error down to the XMLDecoder where I can see the correct data is received, but is not appropriately packaged in the ResultEvent requiring me to override the XMLDecoder, which, I am sure you can imagine, is not very fun. Just wanted to put in my 2 cents. If you are thinking of moving in that direction it would probably be nice to know it doesn't always work for very complicated data types (in my example a collection of objects containing 2 strings and 2 arrays - only returns a collection of 1 string). Granted, it does work 99% of the time, but not always.
I have a web service that is on an internal server. It can be called from any website on our network.
More and more developers are starting to use it. Current probably 20+ pages use this service, and the number is growing fast. I can see a year from now, someone asking what pages are using this service and what methods.
I would like to log the url of the pages that use my web service as the request come in.
It would also be nice to know the method they are calling.I need to do something in such a way, that it does not affect the client web sites.My first thought was that I could write some code in the global.asax.
I have added some code to the Application_BeginRequest to log the request object details, but there does not appear to be anything about the requesting url.
What am I missing? Should I be looking at a different object?
Thanks.
Without disrupting existing users this is going to be difficult. The httpContect.Current.RequestUrl will just return the URL used to call your web service, not which web page called it.
The closest you can do without disrupting existing apps and forcing developers to change them is to grab the HttpContext.Current.Request.UserHostAddress, so you can at least get the IP of the machine calling your service.
Beyond this, what you might want to consider is adding a parameter to your functions for "CallingApp" and then log that in your code. That's pretty much what we did once re realized that we needed to know which apps are calling our service. We actually have an application monitoring service that uses a GUID for every new app we develop, and we pass that GUID to any web service. It[s extra work but to us it was critical because it allows us to know which apps will be affected when we need to perform updates or take the app server down for maintenance.
Edit - added
As a side note, at the point we realized we needed to track this, we had already been using web services for about a year. When faced with the same problem, we created a new set of web services, and included the extra field for the calling app in all of the new services, and then slowly went back and changed the older programs to point to the new services.
IN retrospect, we wish we had known we would need to do this up front because it created a lot of extra work. I'm guessing you'll be facing something similar if you really want to know exactly who is calling your services.
The only thing you can probably retrieve from the consumer is the IP address without changing your interface.
If you can change this you could do this e.g. by adding authentication and logging who is calling what, or by having some simple "token" principle.
However both methods require you to change the interface and therefore break backwards compatibility - which you should never do.
By always ensuring both back and forward compatibility you should not need to know exactly who is calling your service, but only that it is actually used.
#David Stratton
Thanks for your help. I think your suggestions were great. I accually did something very different, after your answer gave me some new ideas.
I should have mentioned that I was generating the web proxy that most of my users were using to make calls against my web service. My client in general do NOT use the proxy that Visual Studio creates.
Here is what did:
I generated my web proxy client again, and added calls to log the httpcontext of the client before every call. Because the proxy is running on the client, he had access to everything I needed. That allowed me to record everything about the client and the specific call they were making. I realize this would not work for most cases. But all of my clients are internal web sites.
It also had the advantage in that the clients did not have to modify their code at all. I just gave them all a new DLL. Problem solved. I get all the tracking data I want, and they did not have to modify their code.
I was stuck trying to solve the problem from the web service's point of view.
I realize that there is still a whole in this implementation, because someone does not have to use my client proxy to call my service. I guess I could force that at some point in the future. For now, they could let Visual Studio genereate a web proxy for my service. However, if they do that I guess I don't care. That is not the recommened way to call my service. I think the only one doing that is an ASP.NET 1.1 web site. When they upgrade, they will probably switch to my generated proxy.
Without implementing some sort of authentication, there isn't a guraenteeted way of knowing exactly who is calling your service - web metrics are the only way you can gauge what volume of traffic is hitting your service.
I'm sure you already know this but the whole point of a web service isn't to know or care who is calling it.
I have successfully used ...
Dim strReferrer As String = HttpContext.Current.Request.UrlReferrer.AbsoluteUri
to get the calling page that called my WEB API 2 Web Service.
Looking around, I can't name a single web application (not web service) that uses anything besides GET and POST requests. Is there a specific reason for this? Do some browsers (or servers) not support any other types of requests? Or is this only for historical reasons? I'd like to make use of PUT and DELETE requests to make my life a little easier on the server-side, but I'm reluctant to because no one else does.
Actually a fair amount of people use PUT and DELETE, mostly for non-browser APIs. Some examples are the Atom Publishing Protocol and the Google Data APIs:
http://www.ietf.org/rfc/rfc5023.txt
http://code.google.com/apis/gdata/docs/2.0/basics.html
Beyond that, you don't see PUT/DELETE in common usage because most browsers don't support PUT and DELETE through Forms. HTML5 seems to be fixing this:
http://www.w3.org/TR/html5/forms.html#form-submission-0
The way it works for browser applications is: people design RESTful applications with PUT and DELETE in mind, then "tunnel" those requests through POSTs from the browser. For example, see this SO question on how Ruby on Rails accomplishes this using hidden fields:
How can I emulate PUT/DELETE for Rails and GWT?
So, you wouldn't be on your own designing your application with the larger set of HTTP verbs in mind.
EDIT: By the way, if you're curious about why PUT/DELETE are missing from browser based form posts, it turns out there's no real good technical reason. Reading around this thread on the rest-discuss mailing list, especially Roy Fielding's comments, is interesting for some context:
http://tech.groups.yahoo.com/group/rest-discuss/message/9620?threaded=1&var=1&l=1&p=13
EDIT: There are some comments on whether AJAX libraries support all the methods. It does come down to the actual browser implementation of XMLHttpRequest. I thought someone might find this link handy, which tests your browser to see how compliant the HttpRequest object is with various HTTP options.
http://www.mnot.net/javascript/xmlhttprequest/
Unfortunately, I don't know of a reference which collects these results.
Quite simply, the HTML 4.01 form element only allows the values "POST" and "GET" in its method attribute
Some proxy servers with tough security policies might drop them. I'm using PUT and DELETE anyways.
I've read that some browsers do not support other HTTP methods properly, though I can't name any specifics.
Rails, in particular, will pack your forms with a method parameter to explicitly set this even if the browser doesn't support those methods. That seems like a reasonable precaution if you're going to do this.
I say use all the features of HTTP, browsers be damned, lol. Maybe it'll inspire more complete and proper use of the HTTP protocol moving forward. There's more happening on the net than just POSTs and GETs. About time browser implementations reflected this.
This depends on your browser and Ajax library. For example jQuery supports all HTTP methods even though the browser may not. See for example the jQuery "ajax" documentation on the "type" attribute.
The Restlet Java framework lets you tunnel PUT and DELETE requests through HTML POST operations. To do this, you just add method=put or method=delete to your URI's query string, eg:
http://www.example.com/user=xyz?method=delete ...
This is the same as Ruby on Rails' approach (as described by #ars above).
Personally, I really don't see any purpose for using PUT or DELETE in a web application. All operations that an application performs are read or write, aka input output. Why do you need to distinguish the nature of the operation in the header of the HTTP request?
I could make ajax calls with the same url of form /object/object_id
and do multiple operations like delete, update, get the value, or create.
Just by looking at the URL, I have no clue which one it is.
By using GET and POST only, my urls will be:
/object/id/delete
/object/id/create
/object/id/update
/object/id --> implied GET
etc.
Based on my limited experience, this is a lot cleaner than hidden header request types in many cases.
I am not saying one should never use PUT or DELETE, just saying, use them only if absolutely needed.
Refer to "RESTful Web API" by Leonard Richardson to read more about different use cases and conventions regarding HTTP request methods in a RESTful web api.
(under asp.net enviro)
I will be sending data to a central server via a web service, and I want to hash the data to ensure that it didn't get corrupted during transfer.
Which hash method should I use?
Can I hash when the web service is passing objects?
I would recommend using WCF is you have a situation where you might actually have a heavier traffic while requiring reliable transmission. It supports standard SOAP, Binary, etc.
It got all the bells and whistle you will need.
Cheers
Preferably use SHA1. You can also use MD5.
You could also use Web Services Enhancements (WSE) 3.0 to sign your messages. The nice thing is that everything is built right in, so you won't have to do a whole ton of work.
There's a wide variety of turn-key security options, but it sounds like you would be the most interested in the AnonymousOverCertificate solution. For your implementation, you could define a couple of really simple policy files.
Bear in mind you'll need to use WSE 3.0 on both sides, though. (Client and server sides, that is.)
For more information, check out the link below. It gives a general overview of WSE 3.0.
What's New in Web Services Enhancements (WSE) 3.0
I'd recommend just calling GetHashcode() on the byte array of your data. Send this value as part of the webservice call and verify that they match on the other side.