We have been using soap based webservice till now. Now looking to explore REST service as an option.
For soap - we create a web service descriptor and get the wsdl which can be used by consumer to call the service.
For REST - How can we have the same functionality using REST? And how are inputs provided to this service in REST?
For some of my services we have more than 100 input fields. How can all this be handled ?
I am looking to create a REST service which can be called by consumers.
By its nature REST does not have any contract or schema on its services. It is just an architectural pattern/style of invoking services over HTTP. But there are third party API management frameworks which can give METADATA (not a contract like WSDL) to REST services. Swagger is the most popular one as of now. But unfortunately, webMethods supports creation of REST descriptors using Swagger only from version 9.10 where as you are on version 9.6
You can easily create REST services on webMethods (any version after 8.2.2). Go through the 20 Page documentation that comes with Product suite placed under “_documentation\Integration Server\9-8_REST_Developers_Guide.pdf”. But you cannot share any kind of contract or descriptor files to your consumer as of now in 9.6. But the same is possible from wM 9.10 using Swagger descriptors.
No. Thats not what I mean. You can create a REST resource (as in Provider) on webMethods.
Right Click on designer context menu (Package/Folder)
New → Rest Resource
Give a name to Resource, click NEXT
Select the HTTP verbs you would like to work on and click FINISH
Thats it. Now you have a REST resource configured on webMethods Integration Server. Place relevant logiv( flow service) inside these HTTP verbs in a meaningful way.
For “_get” services, inputs should come as URL query strings
For “_post” or “_put” services, inputs should come as part of HTTP BODY
Integration server will automatically parse these and place them as inputs to your _get, _put and _post flow services
okay… thats somewhat clear to me now. So I write the whole logic inside one of the verb, say get.
As I understand there is no WSDL here… how would the consumers know what is the structure of my input service (‘get’ here ) and what would be the output structure ?
That’s the sad thing with REST resources. They do not have contracts. So, only way a consumer knows your resource URL, inputs and outputs is by providing them with full “documentation”
In Non-webMethods environments, We can create the metadata of REST resources using Swagger (human/machine readable) OR WADL (machine readable only)
but as you are looking for solution on webMethods version that is older than 9.10 I must say there is no out of the box feature to generate the same. It is supported from webMethods 9.10
how are you exactly trying to call this resource? Are you using some client like SOAP UI or other REST clients like POSTMAN? If you are trying to put this URL in browser and run it then it wont work as browser will send it as GET instead of POST
One more question please -
As I said earlier we have been using soap based webservices… If we change to REST, will that be a change for calling application too or they can still call using url with minimal changes ?
You can use POSTMan (chrome browser extension, can be found in chrome store). I am big big fan of it to work on REST services. But SOAP UI supports calling REST services too. It is not just limited to webservices. I have attached a screenshot on where to find the option to create REST service in SOAP UI. Right click on projects and there you go
It will be definitely a change on calling application. But whether it will be minimal or large effect will depend on the approach they consumed your previous webservice.
Suppose, if they consumed the previous webservice and then wrote a wrapper on top of it which gets used by all the dependent usecases, then the effect will be very minimal as the only place to do this change (from webservice call to REST) will be inside the wrapper service. The change will be transparent to the dependent usecases
But say, in you caller application if all the usecases use the consumed webserices DIRECTLY (not wrapper) in their code then it is going to be very very big change as all the places where webservice call is being made should be changed to REST.
If the organization you are working for is large and good then I hope they would be following Approach 1 I mentioned above as it is one of the important DESIGN PATTERNS in the integration space.
Hello,
we are using 9.10 WM version.
We created REST API descriptor for our rest resources; but, we are not able to find the “path” property for the same to set teh relative/alais path.
In your question which path you are talking about.
Is this $path.
Is this the path you are searching for changing the directive name
Is this the path you are searching for web service alias.
