We are looking for a solution to consume a REST full service dynamically in C#. It is something like Wcf test client. In our application, user should be able to provide a service url and then select the required data to be used in the application.
Normally, we will get the WSDL in case of SOAP based service, that describes all about the service, like available methods, parameters to be passed, response type, etc. We, then can use the response, probably using reflection if we execute it dynamically.
How can we achieve the similar information if the services are RESTfull? How do we know what type of data it returns? What is the schema? etc.
I found something called WADL and RSDL can be used to know about the RESTfull services. Do all the REST full services always provide that? If so then how? If not then how will I get to know about the services?
Please note that in our application, we want our user to register any RESTfull service at runtime and consume the response in the application, so we don't want to code for each type of services.
WCF support dynamic discovery in case SOAP. Does it support something similar for REST?
Related
I am a little confused by web services and how they're used. I have created a WCF web service that has an operation contract taking 3 parameters. Then I interrogate our database and return an object matching the data contract. All seems to be good. But how does a third party use our web service? What do I need to provide to them in order for them to use it? Do I need to put a link on my web site? What should that link look like? Thanks!
For third party, you need to share:
Path of Hosted service: it is needed to add service reference.
Information about Service Contract methods: documentation of what exposed operation contracts actually do.
DataContract dll: Only if you are reusing DataContracts.
Some information some times needed to add endpoint if you have to customize default endpoint for client (something like service timeout, packet size etc).
Hope it helps.
Forgive the title, I was not quite sure how to describe the problem I am running into.
I am exposing an API over both SOAP and REST endpoints. I have used some of the WCF extensibility features to use HTTP headers for certain authentication/authorization and logging needs that I have.All of which is working very well WHEN the service is being consumed by an outside client (Not me).
I have a site that will be using the same services, but I don't want to have to worry about consuming these services over an address as I can just initialize them in my site.
Is there a way to use ChannelFactory, or something else to be able to create an instance of my service without specifying an address, and still have it go through the WCF stack and hit my extensibility points?
I was able to figure out exactly what I needed. I wasn't aware that even if you are running your services locally, you can still add a reference to them as a service. This allows me to still leverage the WCF stack and all the extensibility points I implemented.
I have a web service written in C# using SOAP. A client has requested the same service be available as a REST based service.
Is there a clever/quick way I can achieve this, or am I looking at a rebuild from new?
SOAP based services are built with a completely different set of constraints than REST services. If the services is simple then the end result of the two approaches may look somewhat related, but in reality they are two completely different approaches.
SOAP and REST are different not only conceptually but mechanically.
Conceptually SOAP methods are pretty much RPC, remote procedures. So your web methods look like "GetListOfCustomers" and "DeleteCustomer". While in REST you model Customers as resources and use HTTP verbs on these resource. To get the list of customers client will send HTTP GET and server will return customer representation in XML, JSON, HTML or custom format. Customer representation may have embedded URL links that will allow client code to delete customer for example. This is called HATEOAS
Mechanically SOAP is a layer on top of HTTP. Layer that ignores and reimplements existing HTTP capabilities like envelop, verbs, caching, encoding etc. As opposed to REST that relies on all these HTTP features. So mechanically REST is simpler because there is no additional layer that SOAP has.
When you were asked to make existing SOAP service to be available as REST it probably implied purely mechanical aspects. You probably need "XML RPC over HTTP" which will require some work on your part but may not be as hard as redesigning API from SOAP/RPC to REST/HATEOAS.
The solution will depend on how you implemented the SOAP web service.
This is not a "conversion". You will be writing a REST-based service to do the same sorts of thing that your SOAP service does. If you developed your SOAP service correctly, then you will be able to reuse much of the code. You will then be able to deploy a single service that serves both requirements.
Can I write a web service that implements the same methods and returns the same custom objects using both C#/WCF and also Java Web Services? And if so, can I then access the web services using a single web reference but with different addresses?
I'm asking because I have to host a web service that has a GetCitations and GetTerms method for publically exposing our database content. We are on IIS, so I was going to do it with WCF. However, other partners in the project also have to host an equivalent service and they are all Java based.
We are then building a software app that needs to connect to any number of these services (as defined at runtime by a user). I am expecting that we can have one set of classes to connect to these services (but with different endpoitn addresses), but am not sure whether I'm right in expecting this to work.
Is this possible?
And what considerations/restrictions are there?
Thanks.
It shouldn't be a problem, if you make sure that both services have equivalent wsdl files and you use http/soap binding.
I am not sure about using the binary (net.tcp) one with WCF, though. It might be a problem.
One way to do it is to use JAX-WS (Java 6) to expose a method as a web service.
The JAX-WS stack allows for automatically generating the correct WSDL at runtime.
The .NET team can then take that WSDL, and use standard tools to create a mock implementation of that WSDL. This mock implementation is then used as the actual .NET implementation, and you then use standard tools to generate the WSDL for that web service.
You now have to web services with the same semantics each with their own WSDL.
Both Java and .NET can implement a SOAP compliant web service, so the answer is yes, you can write a .NET and a Java webservice that implement the same WSDL.
My understanding is that a c# based client "prefers" SOAP because when you add a web service reference it creates a proxy class from the wsdl found at the url you specify.
Which almost makes it transparent to the c# client that we are even using a web service, it almost feels like we are using a local class library. you call methods and you use objects.
My question is can REST achieve the same affect. I assume that it can't since it doesn't have wsdl and thus visual studio can't generate a proxy class for it. But Please correct me if I'm wrong?
A "run of the mill" REST service cannot achieve the same kind of tight integration with C# - mostly because it lacks the metadata that a SOAP service will provide (with a list of methods and their parameters and all that stuff).
The WCF Data Services (built on top of REST) do work much the same way as SOAP services, since the OData protocol contains extensions for pure REST services that provide metadata information needed to create a good, useful client-side proxy.
REST can be used to generate client side class libraries. For Example You can create proxy classes for MS generated REST services. In fact MS is actively pushing this model for Entity Framework based WCF DATA Services, e.g. those used by Silverlight and RIA applications. check out MS ODATA framework for REST which involves creating client objects out of standard REST queries.
http://msdn.microsoft.com/en-us/library/dd673930.aspx