Say I have an existing SOAP service which I a would like to re-implement using e.g. ServiceStack.
Is that possible - or more specifically: can I e.g. take an existing SOAP specification and implement that using ServiceStack? I haven't been able to figure this out.
Thanks,
Martin
You can see more information about ServiceStack's SOAP Support on the wiki.
In short, the SOAP Support works like the rest of ServiceStack where your models are the master authority and projects-out, so SOAP support is added to your existing models and not the other way round of projecting-in and imposing the SOAP spec onto your models.
Related
DocuSign highly recommends using the REST API instead of SOAP, and they push heavily for that in your initial implementation. They even suggest that new features may one day only be implemented in REST, which is my main concern. I'm leaning toward using their SOAP API anyway for our integration, and my primary question is this:
Let's assume the future scenario I fear - I build my DocuSign integration layer on the SOAP API. Next year, DocuSign does in fact leave the SOAP model behind, releases new features on the REST API only, and I desperately need to use one of those features. Is there any reason that I can't simply leave all of my SOAP integration in place, and implement integration with the new feature using the REST API? I understand that referencing both APIs would bloat the size of my deployment a bit, but I can accept that risk. Other than that, is there any compelling reason that I can't use both side-by-side? Would it break something?
It's perfectly acceptable to use a mix of DocuSign SOAP API and REST API in your integration. In fact, that's a very common scenario for the exact reason you mention -- some features are implemented only in SOAP or only in REST, so it's often necessary to use a mixed approach in order to get the full functionality that you require.
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 know very little about web programming but I need to establish a license generation web service to provide licenses to users of my desktop software.
I have managed to create a working & debugged SOAP service on a Win2003 server but now I have discovered that the interface that I need to provide to my payment processor must be REST.
How would you recommend I deal with this, given that I simply don't have the time to learn PHP and rewrite my web service etc. I could bypass the SOAP altogether and easily create an executable which receives the license parameters and returns an encrypted license, but it's the web interface bit that I am stuck on. I will probably subcontract someone to write a utility for this on elance, but I don't know what to ask for.
Manu thanks,
Michael
You can expose the same service as SOAP based as well as RESTful. Axis2 with WSDL 2.0 has support for this.
Please see this article RESTful Web Services with Apache Axis2 - explains things in detail..
Thanks..
There's no easy conversion from SOAP to REST. SOAP WebServices RESTful APIs use different approaches. I think it is very easy to do with Ruby on Rails (which will take care of 90% of RESTful APi for you). All you need is to implement your logic.
Sinatra example:
get '/hi' do
"Hello World!"
end
I have been reading about REST and SOAP, and understand why implementing REST can be beneficial over using a SOAP protocol. However, I still don't understand why there isn't the "WSDL" equivalent in the REST world. I have seen posts saying there is "no need" for the WSDL or that it would be redundant In the REST world, but I don't understand why. Isn't it always useful to programmatically bind to a definition and create proxy classes instead of manually coding? I don't mean to get into a philosophical debate, just looking for the reason there is no WSDL in REST, or why it is not needed. Thanks.
The Web Application Description Language (WADL) is basically the equivalent to WSDL for RESTful services but there's been an ongoing controversy whether something like this is needed at all.
Joe Gregorio has written a nice article about that topic which is worth a read.
WSDL describes service endpoints. REST clients should not be coupled to server endpoints (i.e. should not be aware of in URLs in advance). REST clients are coupled on the media-types that are transfered between the client and server.
It may make sense to auto generate classes on the client to wrap around the returned media-types. However, as soon as you start to create proxy classes around the service interactions you start to obscure the HTTP interactions and risk degenerating back towards a RPC model.
RSDL aims to turn rest like a hypermedia, in other words, it has more information than a service descriptor like WSDL or WADL. For example, it has the information about navigation, like hypertext and hyperlinks.
For example, given a current resource, you have a set os links to another resources related.
However, i didn't find Rest Clients that supports this format or Rest Server Solutions with a feature to auto generate it.
I think there is a long way for a conclusion about it. See the HTML long story and W3C vs Browsers lol.
For more details about Rest like Hypermedia look it: http://en.wikipedia.org/wiki/HATEOAS
Note : Roy Fielding has been criticizing these tendencies in Rest Apis without the hypermidia approach: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
My Conclusion : Now a Days, WADL is more common that Rest and Integration Frameworks like Camel CXF already supports WADL ( generate and consume ), because it is similar to WSDL, therefore most easy to understand in this migration process ( SOAP to REST ).
Let's see the next chapters ;)
Isn't it always useful to programmatically bind to a definition and
create proxy classes instead of manually coding?
Agree wholeheartedly, this is why I use Swagger.io
Swagger is a powerful open source framework backed by a large
ecosystem of tools that helps you design, build, document, and consume
your RESTful APIs.
So basically I use Swagger to describe my models, endpoints, etc, and then I use other tools like swagger-codegen to generate the proxy classes instead of manually coding it.
See also: RAML
There is an RSDL (restful service description language) which is equivalent to WSDL. The URL below describes its practice http://en.wikipedia.org/wiki/HATEOAS and http://en.wikipedia.org/wiki/RSDL.
The problem is that we have lots of tool to generate code from wsdl to java, or reverse.
But I didn't find any tool to generate code from RSDL.
WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate
However, REST uses the network protocol by using HTTP verbs and the URI to represent an objects state.
WSDLs tell you at this place, if you send this message, you'll perform this action and get this format back as a result.
In REST, if I wanted to create a new profile I would use the verb POST with a JSON body or http server variables describing my profile to the URL /profile
POST should return a server-side generated ID, using the status code 201 CREATED and the header Location: *new_profile_id* (for example 12345)
I can then perform updates changing the state of /profile/12345 using the HTTP verb POST, say to change my email addresss or phone number. Obviously changing the state of the remote object.
GET would return the current status of the /profile/12345
PUT is usually used for client-side generated ID
DELETE, obvious
HEAD, gets the status without returning the body.
With REST it should be self-documenting through a well designed API and thus easier to use.
This is a great article on REST. It really help me understand it too.
WSDL 2.0 specification has added support for REST web services too. Best of both worlds scenario. Problem is WSDL 2.0 is not widely supported by most tools out there yet. WSDL 2.0 is W3C recommended, WSDL1.1 is not W3C recommended but widely supported by tools and developers.
Ref:
http://www.ibm.com/developerworks/library/ws-restwsdl/
The Web Application Description Language (WADL) is an XML vocabulary used to describe RESTful web services.
As with WSDL, a generic client can load a WADL file and be immediately equipped to access the full functionality of the corresponding web service.
Since RESTful services have simpler interfaces, WADL is not nearly as necessary to these services as WSDL is to RPC-style SOAP services.
I'm trying to get a handle on web services and was wondering if I get some help from the SO community. In particular, a I'm trying to get a handle on WSDL, UDDI, SOAP AND JAX-P, because I'm most familiar with Java.
Edit:
Please tell me if I'm right or wrong on these definitions:
WSDL: This is a schema to describe what kind of XML documents can be passed to and from the WS.
UDDI: This is the most confusing to me ATM and don't really have a good def.
SOAP: Basic protocol used.
JAX-p: This is used for parsing the XML documents.
As an alternative to the SOAP path you might also want to consider looking into REST-based (or RESTful) web services, for Java in particular JAX-RS: The Java API for RESTful Web Services.
That's a very broad question. At a high level, SOAP refers to the XML protocol of the messages that travel back and forth. WSDL is another XML protocol that defines the format of the SOAP messages (very useful for tools that translate SOAP requests and responses for you). Typically a SOAP service endpoint will also have a way to access the static WSDL document about that service (e.g. if a service is hosted at http://myservice.com/services/MyService, the WSDL will usually be served from http://myservice.com/services/MyService?WSDL in most implementations). UDDI is yet another XML protocol that describes queries to a registry asking for information about SOAP services stored there.
Learn SOAP and WSDL first. UDDI is not all that widely used (although getting more so slowly). JAXR is the Java API around UDDI, which means that you probably should never need to write a raw UDDI query yourself.
JAXP is just a Java XML parser API. It can be used for lots of things, not just SOAP and WSDL. Apache Axis is a good Java SOAP client tool, and wsdl4j is a good WSDL parsing tool, although Axis will also autogenerate SOAP requests and responses from Java objects for you by parsing WSDL. Optimally, you should never need to parse a WSDL document yourself, but you often have to in practice when the tool doesn't quite do what you want.
If you want a practical introduction, do the Spring Web Services tutorial: http://static.springframework.org/spring-ws/sites/1.5/reference/html/tutorial.html
Web Services messages are defined according to the WSDL schema. Some parts will define where the message is supposed to go, and some parts will define the message contents.
Good Thomas Erl introduction to whats in the WSDL
They can be embedded in SOAP messages for transmission.
UDDI is like a look up directory to find web services you might use / consume. If you're trying to tie two specific systems together as opposed to broadcast the offering of some services, its probably irrelevant to you.
In Java, you can use a web services containers like Apache Axis to comprise your web services. JaxP could be used to parse XML documents for transmission etc.
You should read some overviews from the web and then post some more specific questions :-) Maybe if you described what you were trying to achieve, some readers would have experience with similar requirements.