With SOAP WebSevices and WSDL it's very easy to generate a Java WebService client with wsimport.
Is there a similar way to do this for Java REST clients?
Thanks, Simon
Take a look at Alchemy Rest Client Generator. It can generate a jersey 2.0 java client for your JAX-RS REST services by integrating into your server builds.
The client will mimic the exact service API. However this project does not yet support WADL and does not handle marshalling and demarshalling of your transfer objects.
Disclaimer: I am the author of this project.
Do you have a WADL descriptor for your REST service?
If so, you can use wadl2java or maybe something built-in in your IDE (IDEA for example has a wizard for that).
Related
I have a small routine that programmatically builds an XML file that resides in memory based on a dataset that I send to the routine (it's called CreateAdXML()).
My buddy says I should turn it into a 'webservice', but I'm not quite sure what he means or how to do that. Can someone offer me some pointers? Is it relatively easy to take existing code for an asp.net site and turn it into a webservice?
There are many possibilities to create web services for an ASP.NET application. It all comes down to what you actually need:
If you need secure connections, advanced serialization, WSDL support etc...
Go for WCF (http://en.wikipedia.org/wiki/Windows_Communication_Foundation)
MSDN : http://msdn.microsoft.com/en-us/library/vstudio/ms735119(v=vs.90).aspx
If you only to expose a few methods:
Go for WebMethods (that's deprecated + quick and dirty in my opinion)
WebMethod tutorial: http://msdn.microsoft.com/en-us/library/byxd99hx(v=vs.90).aspx
If you need to expose data through a standardized interface, interoperable and bandwith-friendly service (that's called REST):
Go for Web APIs
Official page: http://www.asp.net/web-api
There also a lot of webservices frameworks available on codeplex, do some research to see if one suits your need better. A few well known are RestSharp and ServiceStack.
My advice:
From what you described, I would go with WebMethods for test purposes only. Once you know more about the client that will consume you web service, chose one of the apropriate framework.
If however you need to expose more methods, you should consider using Web APIs or WCF from the start, since these are much cleaner web service frameworks. It will also make you service stack MUCH easier to maintain.
It sounds to me more like you need to make it a utility method instead of a web service, as this will allow all of your web project to use this functionality, but not necessarily expose it beyond the boundaries of your application.
If you insist on making it a web service, then read A Beginner's Tutorial for Understanding Windows Communication Foundation (WCF).
It is fairly easy to create web services from ASP.NET code (VB.NET/C# etc..)
You can use the following link to help you understand more about ASP.NET Web Services.
http://msdn.microsoft.com/en-us/library/t745kdsh(v=vs.90).aspx
HOW TO: Write a Simple Web Service by Using Visual C# .NET
But all of the other answers are good too.
ASP.NET Web API seems to lack the service contract / data contract features of WCF web services which would have generated a wsdl that could be used to generate proxy classes. I'm wondering whether Web API is intended for consumption in a service-oriented architecture or if it's meant simply for Ajax consumption.
Web API (as far as I know) does not support WSDL generation. If you absolutely require a WSDL, WCF REST might be an option, though no longer supported.
Service-oriented architecture does not require the use of SOAP or reliance on a WSDL and RESTful services aren't restricted to being useful only for AJAX requests. There are quite a few RESTful web service client libraries available from nuget that makes interacting with these services easier. Though it might not be as simple as using code-gen, creating a library of POCO classes you can share with other C# clients also makes things easier. Hope that helps.
I can't find anything on the implementation of service discovery for the ASP.NET Web API. For a new project I need to make a decision between WCF and Web API. The service element will be consumed by a variety of clients, mobile, client-side JavaScript but also an ASP.NET website.
For the website the convenience of being able to generate a client against a WCF service is obviously a plus. I am not that familiar with RESTful web services but I see that there is Web Application Description Language (WADL). Maybe it is my ignorance but surely it is a good thing to be able to advertise the correct way to consume your service?
My main question: is there anything that generates a WADL or similar for WEB API?
Secondary question: this tool looks like it generates a client based on a WADL, is there anything else that makes life easy keeping a client up to date with a RESTful web service?
There is a considerable amount of work going in there. It is not finished but watch the space.
Having a look here (and newer Yao posts):
http://blogs.msdn.com/b/yaohuang1/archive/2012/05/21/asp-net-web-api-generating-a-web-api-help-page-using-apiexplorer.aspx
Also
http://blogs.msdn.com/b/yaohuang1/archive/2012/06/15/using-apiexplorer-to-export-api-information-to-postman-a-chrome-extension-for-testing-web-apis.aspx
I blogged an approach to generating WADL with ASP.NET Web API here: http://blogs.msdn.com/b/stuartleeks/archive/2014/05/20/teaching-asp-net-web-api-to-wadl.aspx
I have to write an app for iPad that would take data from SQL Server and post it to the iPad. I looked up on this over the Internet and found that i have to write a web service to expose the data from SQL server using ASP.NET. I did an app previously in android that would take data from my dropbox a/c and display it to the user. I made use of the drop-box api available. I was wondering if anything like that exists for SQL? Also, i have to code in Obj-C for the iPad, so how will
i write ASP.NET code? I have more doubts.
Thanks in advance.
There are many options for web services. If you are developing in ASP.NET and don't want to invest to much time in just accessing the data I would suggest some software that will help you generate the source code.
WSSF (Web Service Software Factory) is software that will assist you in creating a SOAP web service and it generates source code for you. I do recommend however working through a tutorial first before just jumping into using this. WSSF uses visual studio as well.
Once you have a web service that packages your SQL data for communication through http requests. You will need to parse the data communicated in Objective-C. For this you'll find SudzC to be very helpful.
SudzC generates all the source code for accessing your web service in Objective-C, given the WSDL.xml file of your web service (a file that lays out the design of your web service).
Although these software will save you a lot of coding, I wish I could tell you that this will be a short and easy process. However this is vary rarely the case, developing this will take you a couple of days.
I do know that people often use RESTful web services when dealing with the iOS enviroment, although I do not have the same kind of experience with them as I do SOAP web services. I hope that this information is helpful to you.
I've done this. The best way is to use .NET 3.5 or higher to create a WCF (Windows Communication Foundation) project. These projects will let you communicate with your mobile application using REST or SOAP. They also let you send data in XML or JSON format. You will then need to create a REST or SOAP client in your IPad application to communicate with the server.
Use OData. See Creating an OData API for StackOverflow including XML and JSON in 30 minutes for how to publish your SQL Server data as an OData service. See Consuming OData using Objective-C for how to consume the OData service from your iPhone app.
We have an ASP.Net C# application that requires some form of a web services implementation for integration with other applications. Currently we have been looking at servicestack and also using an ESB e.g. Mule.
I am trying to figure out the best way to integrate an ESB like Mule into our ASP.Net application.
Do we need to build a web service into our ASP.Net application so that an ESB can integrate with it?
If yes what would be a good approach for selecting a web service type (e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an ASP.Net application and Mule?
Do we need to build a web service into our ASP.Net application so that
an ESB can integrate with it?
Usually it's the other way around. An integration middleware, like Mule, speaks tons of protocols just for the sake of being able to connect to existing systems without changing them.
If yes what would be a good approach for selecting a web service type
(e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an
ASP.Net application and Mule?
If your application has really no pre-existing channel you could use to integrate with (not even a simple web form HTTP POST? really?) and you want to expose an API so an integration middleware can connect to it, pick the architecture/technology that maps to the API style you're creating (REST for a resource oriented API, SOAP for a RPC oriented API).
This sounds backwards. What are you required to integrate with, and what capabilities are you trying to provide?
A web service is decoupled from its implementation, you would choose to use a web service if you're trying to expose your system capabilities in an interoperable way so that it's accessible by a broad range of clients.
What you do within a web service is up to you, i.e. you could then for example connect with your ESB. Nothing is precludes you from doing that. ServiceStack also supports hosting from within an existing ASP.NET (or MVC application) see the Hello World example for different ways of configuring ServiceStack.
REST / RPC has to do with the design of your web services and ServiceStack supports both models. i.e. inherit from RestServiceBase if you want to provide different implementations when the service is invoked with different HTTP Verbs. Inherit ServiceBase if you want the same implementation to be used no matter how it was invoked. This article shows the difference between REST vs RPC/SOAP - and how you can support both in ServiceStack.
So if your exposing a single operation (or want to support SOAP) use ServiceBase, if your exposing a 'Resource' where you want to allow it to be managed using different HTTP Verbs use RestServiceBase.