I'm new in this technology, so please excuse me for the question.
I have a WSO2 ESB configured on server. I managed to configure different Proxy Services one by one, the thing i'd like to do, since they are all child of one service to put them into one proxy and use it with parameters.
Something like:
http://localhost:8290/services/URL1/{id}
http://localhost:8290/services/URL2/{id}
I can't find comprehensive explanation on how to do this.
Could someone provide me with the proxy source example with more then one endpoint defined there, if it is possible.
Thanks a lot in advance,
Liudmila
You can use REST apis , there you can use url mapping and url templates as you want.
check the document[1]
https://docs.wso2.com/display/ESB470/Getting+Started+with+REST+APIs#GettingStartedwithRESTAPIs-URLmappings
Related
I'm trying to provide contract for HATEOAS service using spring-cloud-contract solution. However I've stucked with links to HATEOAS resources, as you can run stub server on any random port the question is how to include absolute link returned by contract response and then used by consumer??
Is there any way to inject current stub server port into mapping?
Many thanks in advance
The best solution to use contract with HATEOAS would be to use the Spring RestDocs solution (you can check out the restdocs branch of Oliver's RestBucks sample https://github.com/olivergierke/spring-restbucks#documentation--client-stub-generation). We're still working on figuring out the best user experience so any feedback is more than welcome.
As for Is there any way to inject current stub server port into mapping?, well, there's nothing really that comes to my mind. I guess you'd have to hardcode the port.
I was reading about this GRPC Gateway and wondering if using only the REST endpoint generated by it makes a service more reliable and efficient in any way.
If I'm sending JSON over HTTP first, I lose all the RPC/pb lightweight and async capabilities, right?
What is the point for using this lib, aside from the flexibility to choose one or another service layer?
Your understanding is correct. The main purpose of the project is to keep an avenue for the clients that may not be able to use gRPC, but have the ability to connect to an HTTP/JSON server supported without additional manual work.
I am using Jersey/Tomcat6 for dveloping some web services. Compared to what I did for SOAP services, I am not getting the idea what should I share to my clients once the services are developed...just the URL of the web service ?? For SOAP, the WSDL file was enough, as the clients self-generated the stubs.
My service returns a list of User objects (with 2 Strings) in JSON format. How would my clients de-serialize the JSON if I share just the service URL with them ? Do I need to share the entity bean (The User class, and the list class) on my server side too ?
I have been reading about some WADL files for REST...are they helpful here ?
Thanks for any help !
It sounds like you probably want to put together an example client to give to your, er, clients to show them how to use the REST service. Ideally, of course, your REST service would fully support HATEOAS (Hypermedia As The Engine Of Application State), and so the means of traversing the resources to get the desired results would be discoverable; I've found that real HATEOAS implementation is rare, though. For a RESTful-ish service (one that doesn't fully support HATEOAS), example clients are useful. You can usually implement your example client in HTML with some Javascript; this makes everything very accessible for most REST client users.
Is there a good reason to deploy or consume a SOAP service without using a WSDL "file"?
Explanation:
I'm in a situation where a 3rd-party has created a SOAP service that does not follow the very WSDL file they have also created. I think I am forced to ignore the WSDL file in order to consume this service. Therefore I'm researching how to do this.
What I am really wondering is why it is even possible to do this? What is the intention?
Is it designed so that we can use poor services made by poor programmers? Surely there must be a better reason. I almost wish it wasn't possible. Then I could demand they write it properly.
The WSDL is supposed to be a public document that describes the SOAP service, so describes the signatures of all the methods available in the service.
Of course there may be service providers who want to expose a service to certain consumers, but who don't want to make the signature of the service public, if only to make it a little bit harder for people they don't want using the service to find it or attempt to use it. The signature of the services might expose some private information about the schema of their data for example.
But I don't see any excuse for writing a WSDL that doesn't match the service. I would worry that if they can't get the WSDL right what is the quality of the service going to be like?
To answer the other question yes you can consume the service without the WSDL. If you are using Visual Studio for example you could have VS build a proxy for you based on the incorrect WSDL and then tweak it to match the correct service method signatures. You just need to make sure your data contracts and method contracts in your proxy match the actual service data contracts and method contracts.
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.