I'm using VS 2012. My server side is WebApi 4.5 and my client side application is WPF.
I want to consume my odata service at the client side using "Add Service Reference" but I don't know how to generate the metadata file.
You should point it to the root of your OData endpoint. If you're using the default routing, it's http://<address>:<port>/odata. If you've got a different routing, you should check your MapODataRoute line in WebApiConfig.cs.
Clarification edit:
The metadata itself can be found at http://<address>:<port>/odata/$metadata. However, as I said, in order to add it as a service reference, it should be sufficient to point just to the root.
Related
Morning Guys
I've been trying to manage an API created in asp.net WebApi, with the WSO2 Api Manager.
I've used the following doc with no sucess:
https://docs.wso2.com/display/AM200/Create+and+Publish+an+API.
The sample shows the use of ".asmx" endpoint, and in my case I have a simple http url (http://sample.enterprise.com/api/TestService), I want to http get a jsont result by WSO2 using an url like this.
Any clues ?
Thanks
WSO2 documentation is not great. The link you provided guides you through Designing and Publishing an API, but nowhere do I see any explanation for publishing an existing API. You essentially have two choices:
Choose Design New API and define the resources exactly as they are defined in your existing API (name, action, and required parameters much match exactly). Once you reach the Implement tab, choose Managed API and provide the production endpoint for your API. If this sounds overly complicated, you also have...
Choose I have an existing API and import your API's swagger definition from file or API endpoint. Keep in mind that importing swagger directly from your API requires connections between your Publisher node and the API endpoint if you have a distributed API Manager deployment strategy.
You can find tools to help you generate a swagger definition for your APIs here. For Web API projects like ours, you might want to consider using swashbuckle from the nuGet repository.
I would like to connect to a SOAP webservice (HP Operations Manager Incident Web Service) using a .NET client based on code generated by adding a service reference. The generated proxy creates a client that implements the DuplexClientBase class. The service is IIS hosted with a self-signed certificate and I need to sign in using basic authentication.
I ran into two problems trying to connect to this service:
I have not yet been able to find the right binding configuration. Either the binding does not support duplex or https traffic with basic authentication.
When adding a .NET 2.0 web service reference (the binding issue is not there) I am able to connect to the service but the “Action” header element which is required by the service and should look like <a:Action s:mustUnderstand="1"> http://schemas.xmlsoap.org/ws/2004/09/enumeration/Enumerate</a:Action> is not included in the header. When I create a SoapExtensions and inspect the contents of the Action property of the SoapMessage object in the ProcessMessage(SoapMessage message) method it contains the right value but the property is not serialized in the message header.
I would like to know if any of you could suggest what to do:
Proceed with a 2.0 legacy reference and find a way to add the Action element in the SOAP header. (eg adding a SoapExtension)
Fix the binding a find a way to connect to the https site with faulty certificate (wsDualHttpBindingdoes not support HTTPS, BasicHttpBinding does not support duplex, PollingDuplexHttpBinding does not seem to work in a console application)
Try to generate the code in a way that no duplex communication is required. Is this possible?
It is possible to make a .NET 2.0 client support WS Addressing. You can accomplish this by downloading and installing Webservice Enhancements 3.0 (WSE). http://www.microsoft.com/en-us/download/details.aspx?id=14089
When you add a reference to the Microsoft.Web.Services3 assembly and change the code generated by adding the web service reference. Change System.Web.Services.Protocols.SoapHttpClientProtocol into Microsoft.Web.Services3.WebServicesClientProtocol and the code will support WS Adressing. The action element will now be added to the SOAP header.
Although this workaround does the job I still would prefer a WCF service reference connection.
If REST based web services are as simple as GETing and POSTing to a url and parsing the response wht exactly do we need a wsdl? Whats the point. I understand that when using SOAP based services it is used to construct the SOAP requests and responses but dont really see why visual studio provides me with a wsdl when I create a REST based service...
WSDL is designed to allow clients to discover service capabilities, primarily at design time. REST has the hypermedia constraint that requires that all service capabilities should be discoverable at runtime via the linked representations that they return.
Proper REST services are naturally discoverable therefore there is no need for a WSDL specification in addition.
There is no point in WSDL for REST services created with WCF because WCF supports only WSDL 1.1 (or 1.0) which cannot describe REST seevice. If you try to use WSDL generated for WCF REST service to create a client proxy you will not be able to call the service anyway. Visual studio templates for REST don't expose metadata so you will get useless WSDL only if you add serviceMetada behavior (and possibly also mex endpoint) yourselves.
WSDL 2.0 and WADL supports description of REST services and the point is similar as with SOAP services - describe what you can do with the service but in the REST way.
There's no point. WSDL is just a standardized description of what a service exposes and how can be invoked. You don't need WSDL, but you need some way of documenting what can be done with your service, so that clients know how to invoke it.
I am trying to create a sort of "bootstrap" web service using a classic .net C# .asmx page and not WCF. (The business requirements for this project are specific and do not want a WCF service).
Basically, I am trying to do this:
Create a new web service (I have no problem doing this)
That service needs to make a SOAP based call to a Sharepoint Web Service
I need to consume that service
I need to add additional pieces of information for my web service to the SOAP result (No problem here either)
The issue I have having is with point #2 and #3. I have found plenty of articles using WCF to consume SOAP based Web Services or using "Linq" to connect to sharepoint etc., but that's not what I'm looking for.
What I am looking for is simply a step by step process of what I need to do to push me in the right direction.
Example:
add a web service reference??
add this line(s) of code to create a new SOAP request??
add this line(s) of code to parse and consume the service??
Thank you very much in advance!!!
Sample code would be greatly appreciated as well!
There's nothing magical about the fact that it's a web service. Just use "Add Service Reference" and then treat it like any other piece of code referencing a web service.
Also, are those who wrote the requirements aware that a WCF service can expose a basicHttpBinding endpoint that looks exactly like an ASMX web service endpoint? It would also have the benefit of all of the features of WCF, in addition to not using what Microsoft considers a "legacy technology".
The SharePoint Developer Center at MSDN would be a good place to refer to for general information, tutorials, etc. Server and Site Architecture: Object Model Overview in the Windows SharePoint Services 3 SDK would be a good place to start learning about the SharePoint object model, as the terms (SPSite, SPWeb, etc.) that you'll come across in examples can be confusing.
Basically you will want to add your web reference to the SharePoint web service that you intend to use. The specific reference that you use will depend on what you're trying to accomplish, there's a whole list of available Windows SharePoint Services Web Services. Those are for general SharePoint tasks such as interacting with lists and sites; there's also a whole separate set of web services for SharePoint Server which is what you would use for interacting with the Business Data Catalog, Enterprise Search, and any of the other features that come with SharePoint Server, not Windows SharePoint Services.
When you add the web reference in visual studio, it will automatically generate the proxy in your project against the remote web service and you use the generated proxy to do what you want to do. However, working directly against the web services, pretty much everything will return a generic XmlNode that you'll have to deal with, so if you're working in .NET, a much better alternative to using the web services directly would be to download the SharePoint SDK and program against the server object model.
If you do end up using the object model, make sure you read both of these thoroughly:
Best Practices: Common Coding Issues When Using the SharePoint Object Model
Best Practices: Using Disposable Windows SharePoint Services Objects
Here is small tutorial on what you're trying to do:
http://www.xefteri.com/articles/show.cfm?id=15
I just hit a huge brick wall with Paypal. I had created a regular C# project to create some wrapper classes using their WSDL.
If you create a non-web project, the only option you get to add a wsdl is a Web Service Reference. And this builds kinda the same set of proxy classes as a Web Reference would but not really..it adds more that even the PayPal guys are not aware of.
So I was this entire time looking for the right Interface in this list of proxy classes to use as the service (SoapBinding) and the PayPalAPIAASoapBinding was not there I kept telling our PayPal point in contact.
I could only see the following 2 Interfaces that appeared to me what I needed to use since I did not see a PayPalAPIAASoapBinding which you CAN see in a Web Reference based service reference:
PayPalAPIAAInterfaceClient
PayPalAPIInterfaceClient
So I figured out oh, I probably had created a Service Reference vs. a Web Reference which Web Reference is an option in a Web project. But I don't want my service reference tightly coupled to my web project. So that's why I created the C# Project.
So what the heck is a Service Reference vs. Web Reference? And how am I supposed to separate this out into anther project if Service Reference is going to throw me a loop and give me a set of different interfaces than a Web Reference would?
Also, to make things even MORE confusing, VS 2008 has a Web Service Application project.
So what do I use? We're using the .NET 3.5 framework and we're not ready to move to WCF. So can I still use the new Service Reference even if not using WCF or what? IF you're using .NET 3.5 and not WCF yet and you still want to do basic web services, do you still go the Service Reference route and just not use the WCF framework? Meaning can it be used like a .NET 2.0 Web Reference still, just that you're going to get an entirely different generation of the WSDL?
Add Web Reference is the old-style, deprecated ASP.NET webservices (ASMX) technology (using only the XmlSerializer for your stuff) - if you do this, you get an ASMX client for an ASMX web service. You can do this in just about any project (Web App, Web Site, Console App, Winforms - you name it).
Add Service Reference is the new way of doing it, adding a WCF service reference, which gives you a much more advanced, much more flexible service model than just plain old ASMX stuff.
Since you're not ready to move to WCF, you can also still add the old-style web reference, if you really must: when you do a "Add Service Reference", on the dialog that comes up, click on the [Advanced] button in the button left corner:
and on the next dialog that comes up, pick the [Add Web Reference] button at the bottom.
If I understand your question right:
To add a .net 2.0 Web Service Reference instead of a WCF Service Reference, right-click on your project and click 'Add Service Reference.'
Then click "Advanced.." at the bottom left of the dialog.
Then click "Add Web Reference.." on the bottom left of the next dialog.
Now you can add a regular SOAP web reference like you are looking for.
Adding a service reference allows you to create a WCF client, which can be used to talk to a regular web service provided you use the appropriate binding. Adding a web reference will allow you to create only a web service (i.e., SOAP) reference.
If you are absolutely certain you are not ready for WCF (really don't know why) then you should create a regular web service reference.
In the end, both do the same thing. There are some differences in code: Web Services doesn't add a Root namespace of project, but Service Reference adds service classes to the namespace of the project. The ServiceSoapClient class gets a different naming, which is not important. In working with TFS I'd rather use Service Reference because it works better with source control. Both work with SOAP protocols.
I find it better to use the Service Reference because it is new and will thus be better maintained.