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
Related
I've been reading around trying to understand what RESTful API is all about. I guess I understood the general outlines and a bit about how it's related to HTTP and all that.
In fact, one of the jobs I recently applied for required a 'must' knowledge of a RESTful API!! The job description was messy anyway and seemed it had been written by an HR person, or somebody who didn't actually have an advanced technical knowledge.
I fail to see how, as a frontend developer / UI/UX designer, I could benefit from the vague RESTful API stuff? What's the connection?! Should really be bothered?
Thanks!
Simple and Precisely NO.
For only a front End Developer; it is not necessary, it is must (or SOAP bases API) for BackEnd Application Developer.
I am Android app Developer, made REST api for my app and my friend is just working on Web Page UI for that APP.!
Ajax calls are little to know for you.!
But one should know little bit about APIs, it never hurts :)
RESTful api, and web services in general, are a way to abstract back ends from front end developpers. It allows front-end developpers to do their interfaces without the need to code any server-side logic.
Web services contain all the business logic. As a front-end developper, you'd need to know how to interact with such services, but the whereabouts of the api call are not required of you to understand.
Finally, it's a way to define clear separation between what the application looks like and what the application does.
REST is a way to think applications. To make short, the client is stateless and you use HTTP methods for what they are designed to in order to interact with your server resources. You also leverage HTTP status codes, media types, content negotiation (Conneg).
If you want to know more about principles of RESTful services and Web API, you could have a look at this link: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
Hope it helps you,
Thierry
From client perspective the two main differences between REST and other e.g. SOAP webservices, that you have to use stateless communication (so you won't have a server side session, login, logout, etc...) and you have to use hyperlinks as request templates instead of building request from scratch. Because of these constraints your client breaks much harder by API changes.
I have a requirement where I need to run an RFC from an ETL (Datastage) job. It can be done by executing a unix command also, of course (the Datastage server is unix). I don't think they have the SAP plug-in for Datastage, though.
I've tried and succeeded using the startrfc command fired as a unix script, but the client's preferred solution would be using SOAP - whih I don't know much about, but I do have the URL for the RFC. Now, only if I knew how to use it...
Any ideas? Experiences? Tutorials? I'm grasping at straws at this point. This is quite, quite different from stuff I'm used to.
Any and all help much appreciated!
Like Ben said,
You should ask the SAP responsible for an SOAP endpoint in their system.
If you or the SAP staff are looking for an explanation how to expose a RFC as Web Service, there are a lot of articles about it on the SAP Developer Network.
E.g. this one: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f02b33fc-9eb1-2c10-0599-f2ef9fb5c5b6?QuickLink=index&overridelayout=true
If you have a URL pointing to the RFC it sounds like they may have exposed it as a web service. If this is the case you can just tack a ?wsdl on the end of the URL and use the WSDL to generate a web service proxy on the DataStage side.
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.
I'm an experienced client application developer (C++/C#), but need to come up to speed quickly on writing server side code to perform RESTful interactions. Specifically, I need to learn how to exchange data with OpenSocial containers via the RESTful API.
The RESTWiki is a very good resource and then there is the classic "How I explained REST to my Wife".
However, don't forget to go read about it directly from the source, it is not as difficult a read as it may first seem.
And I am assuming you will be doing REST over HTTP so this will come in very handy.
Lastly, considering OpenSocial supports the Atom Publishing Protocol, this will be useful.
Enjoy.
RESTful Web Services
I found this this to be a good introduction to RESTful web apps, although it doesn't refer to OpenSocial containers.