With WCF, we can create services that can accept leverage HTTP POST and simple accept an XElement as it's parameter. I'd like to do something similar with a workflow service so that I can use jQuery to post an xml infoset to a service, have it run through a bunch of rules and then return an xml infoset.
With a WCF service, I can simply decorate the operation w/ WebInvoke and go on my merry way. Is it possible to use WebInvoke w/ a Workflow Service and if so, how should I go about?
Workflow services are currently tied to traditional WCF SOAP. You cannot use the WCF REST API (i.e., the WebHttp binding) with WF 4 currently.
Related
I read some articles and i search many about differences between Rest WCF vs Web api but I just find difference between WCF vs Web api , I find some difference:
WCF Rest=>
a)It support HTTP GET and POST verbs by [WebGet] and [WebInvoke] attributes respectively.
b)To enable other HTTP verbs you have to do some configuration in IIS to accept request of that particular verb on .svc files.
c)Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified.
d)It support XML, JSON and ATOM data format.
and
WebApi=> a)Unlike WCF Rest service, it use the full featues of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
b)Responses are formatted by Web API’s MediaTypeFormatter into JSON, XML or whatever format you want to add as a MediaTypeFormatter.
I want know other differences between them, and when is it better to use WebApi and when Rest Wcf?
I would say, if you start a new project and you need to expose a REST web interface in .NET, Web API is the way to go because AFAIK, WCF is deprecated. I would only consider to use WCF Rest if you have to expose both, SOAP and REST web interfaces.
WCF is not the good choice for REST because it was not made for it, when they implemented it they did lots of bad hacks. you can see how they try to convert xml to josn here
WCF is NOT deprecated, so powerful, and no framework can be comparable to it yet. but it is not for REST.
I'm looking for best way to automate generation of REST ws.
We have collection of web services (SOAP) with WSDLs generated for them. I was required to provide different APIs to invoke these web services. (PHP, Pyton, REST, CLI ...)
One of requirement is to have REST API for these ws.
What is the best way to generate REST client/server, is there any automatic tools for that?
There is a chance that WSDLs will change each release.
Thanks
It's not possible to generate REST API from WSDL. You can't mix oranges and apples
SOAP is a protocol build on top of HTTP. A WebService is represented by a set of methods/actions. You can see a WebService as sophisticated RPC. Generally we can say that WebServices are about verbs, to call remote methods/actions. A WebService also doesn't have uniform interface and that's the reason why WSDL exists.
REST is architectural style (scope is broader than just API). REST API is represented by a set of resources and representations. A resource is source of an information and is managed via uniform interface. Generally we can say that REST API is about nouns. Because all resources must have uniform interface there is no need for WADL (an unsuccessful attempt to create something like WSDL for REST).
I doubt you can automatically transform verbs into nouns, etc.
Please check the below article that describes how to use WSDL2.0 to describe REST Services. It can only be used if the intended message format is XML.
https://www.ibm.com/developerworks/library/ws-restwsdl/
Instead of rewriting an existing SOAP-based web service, use API Express to present it as a mobile-ready REST service. No conversion necessary. Continue to run the SOAP service and, with a WSDL file and a few configuration parameters, it can easily be integrated into mobile apps as a REST service.
How to Expose a WSDL Service (SOAP) as REST API: https://dzone.com/articles/how-to-expose-a-wsdl-service-soap-as-rest-api
Appery.io API Express: https://appery.io/api-express/
I am trying to perform CRUD against WCF Data Services (OData). The Read portion is pretty well documented across the web… it’s the Create, Update and Delete that I am having trouble with.
As for the documentation, have you looked at odata.org: http://www.odata.org/developers/protocols/operations#CreatingnewEntries
It has a description and samples of all the common CRUD operations against an OData services.
You can also write a sample client application using any OData client (for example the .NET one) and use something like fiddler to see what requests are being made against the service, if you need to see the exact payload shape for your particular service.
You can try this REST PowerShell module that Jaykul wrote.
I want to use a WCF service and consume it using all the mobile platforms iPhone, android, Blackbery, Nokia etc'
Whats my best strategy for using those clients with a WCF service. it will have to be secured of course.
Thanks
amit
I disagree with SOAP and JSON. Use RESTfull service with POX (plain old xml). It will be most probably supported by all platform. Mobile phones can have limited SOAP stack implementations and JSON is usually used with browsers. My friend has BlackBerry and he continuously complains about its support for JavaScript.
To secure your service use HTTPS.
Use a SOAP or JSON endpoint. Most platforms will have support for these (or it'll be easy to find libraries). JSON is more web oriented (Javascript) but will work in other situations as well.
Mono supports WCF so maybe their iPhone and Android will support it as well.
Totally agree with #Ladislav on not expecting clients to be able to consume SOAP. Seems like SOAP stacks are lacking unless your client is native .NET or Java. Your clients will thank you by allowing them to choose JSON (web clients) or XML (system integration). Secure via HTTPS and basic auth or an API key.
If you already have an existing infrastructure of WCF services that you want to aggregate, or adapt, for downlevel clients you could put that POX (or 'REST') service in front of them and let it handle mapping protocols and formats for you. e.g. HTTP/S to TCP/IP and XML or JSON to SOAP.
The upside is that you will make it easier for downlevel clients to consume your services. The downside is that you've added an extra layer, which will cause complexity. Some tools, like WCF Routing Service (free) or Apigee (commercial), coupled with a solid automated deployment proces can help mitigate this complexity.
To build a REST service that supports XML or JSON, create your service with this template, it's designed for .NET 4.0. From there you can configure endpoints that respond in XML or JSON and let your client tell the service what response type it wants.
EDIT You can also have the service respond in a default format to reduce every client having to specify what format.
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="" defaultOutgoingResponseFormat="Json"/>
</webHttpEndpoint>
</standardEndpoints>
Simple task like make AJAX request , pass one parameter and return result, can be done with Web Service and IHttpHandler, so where is the difference ?
ASP.NET web services are in fact a type of HttpHandler that provide an XML based communication infrastructure based on W3C standards (SOAP/WSDL). This means that non .NET clients can interoperate with ASP.NET web services. In your case where you're making a very simple single ajax request to return a simple result, ASP.NET/XML web services may be overkill.
It may be more beneficial/efficient to implement a simple custom HttpHandler rather than invoking all of the plumbing and overhead associated with ASP.NET web services. With a custom HttpHandler you can just send the parameter you need and return exactly the result you want to see without any of the supporting SOAP xml that would be created when using XML web services.