Call REST webservice in XPA 3.3


Gábor Bor
 

Hy Magicians,

One of our client provide us a REST webservice. I tryed to access and get back the response XML, but i can't raise the solution. In the past at August 2018 Andreas said that in an other topic:

"SOAP is basically the only thing supported by Magic (with Apache Axis since 3.3), REST you have to implement by feet - with basically no support by the platform/framework (Magic)."


The access is successfull by the SOAPui and get back the result XML.

Do you have any solution? We are thinking on a .NET code (Invoke), but i would like to solve this task without it.

Best regards,

Gábor


Andreas Sedlmeier
 

Hi Gabor,

When I wrote REST I actually mean all Web API programming different to SOAP, since you can have XML as data exchange format with REST of course too. That does not make it SOAP then however.

One way to get Web Apis (RESTful) work with Magic is by using a API Gateway resp. a reverse proxy. You would the simply build your API as you are used too (like with Swagger or so) and the URL patterns required to map this into Magic like ?app=xxx&prg=yyyy you solve by rewriting the URLs.

Its easy when you have a "internal" webserver (IIS / Apache) connected to your Magic application server. Outside world (API clients) you serve with the API gateway resp. reverse proxy. Look into things like Kong f.i. Then it might become clear what to do.

You can also get similar functionality with MS IIS and URL rewriting. Just not that good ;)

I still have a Magic Web Api example on my todo list which is based on Docker and Kubernetes. Unfortunately getting that work with Xpa Single user on Windows is too ambitious and a sponsor for a Linux license I did not yet find ^^. 

Best regards,

Andreas


 

What is wrong with updating a Blob with the results of this function: HTTPGet(Trim(A))      where A contains the URL of the REST webservice ?

The only implementation needed to be done is checking if the result is valid, and processing this result.

I did a quick test with this webservice 'https://jsonplaceholder.typicode.com/todos/1/comments', and I received a nice looking JSON-answer.

(For more info on this service see: https://github.com/typicode/jsonplaceholder )


Andreas Sedlmeier
 

Well fetching a JSON file/object via a http request is not yet exactly building a API with Magic on server side ... I would say. Continue your sample and write the server with Magic. Thats still easy but becomes close to impossible if you start with security, URL patterns and HTTP verbs, monitoring, ingress scaling, .... . A good API gateway gives you all that for free - without a single line of programming. Actually I had to install Kong yesterday as an alternative to Ambassador for a node.js based backend on a machine (VM) on client side and that was a matter of an hour (including PostgreSQL for persistency). Whats wrong with that ? ^^

Andreas


 

The subject is 'Call REST webservice in XPA 3.3'?
What has that to do with 'building a API with Magic on server side'?

That's probably why I was asking.... because 'Call REST webservice in XPA 3.3' can be quit simple....
As indeed the server-side stuff, is most often done better in other tooling.


Todd Baremore
 

Gábor,

I utilize a REST service using the following:

Evaluate Expression    HTTPCall('Post',Trim(p URL),v HTTP Post ANSI BLOB,'')    Return:  Return ANSI BLOB
For this REST service both the Post BLOB and Return BLOB are JSON.

This particular service requires that I first I first acquire a "Token" (just a long string that identifies my session) and that token must be included in the "v HTTP Post ANSI BLOB" above.

To obtain a token I use the same evaluate expression above. The JSON in "v HTTP Post ANSI BLOB"  includes a user id, password and other information about the service I wish to use.  I then parse  "Return ANSI BLOB" to obtain the token.

Todd
On 12/21/2018 4:25 AM, Gábor Bor wrote:

Hy Magicians,

One of our client provide us a REST webservice. I tryed to access and get back the response XML, but i can't raise the solution. In the past at August 2018 Andreas said that in an other topic:

"SOAP is basically the only thing supported by Magic (with Apache Axis since 3.3), REST you have to implement by feet - with basically no support by the platform/framework (Magic)."


The access is successfull by the SOAPui and get back the result XML.

Do you have any solution? We are thinking on a .NET code (Invoke), but i would like to solve this task without it.

Best regards,

Gábor



Andreas Sedlmeier
 

Yes, you are right, I missed the topic a bit ^^.  Really thought was about providing a webservice and the term REST always adds to confusion because it is not REST what most sited do anyway, its simple Web APIs.

For consuming such an API (as long its not websockets) you can indeed use Magic http functions. For the JSON however and the security (OAuth2, ...) you are better off with Java and/or .NET and if you use that anyways, why then do the http request with low-level legacy Magic http functions. You can use Java/.NET for that too.

In the Online/RIA samples there's some samples for Facebook, LinkedIn, Twitter. Thats about consuming Web Apis which are secured with Oauth2/OpenId Connect and data-exchange format is JSON.

Best regards,

Andreas


On Fri, Dec 21, 2018 at 01:58 PM, Luuk wrote:
The subject is 'Call REST webservice in XPA 3.3'?
What has that to do with 'building a API with Magic on server side'?

That's probably why I was asking.... because 'Call REST webservice in XPA 3.3' can be quit simple....
As indeed the server-side stuff, is most often done better in other tooling.


Gábor Bor
 

Dear Magicians,

Thank you for everyone! As i read the answers it have to be absolutely possible. Im on. :) When i successfully solve it, i'll come back with my solution. 

Gábor


Todd Baremore
 

Gábor,

It may be easier to use the the service below to create a working example and then hunt down your problem.
http://www.groupkt.com/post/c9b0ccb9/country-and-other-related-rest-webservices.htm
Todd
On 12/29/2018 4:05 AM, Gábor Bor wrote:

Dear Magicians,

Thank you for everyone! As i read the answers it have to be absolutely possible. Im on. :) When i successfully solve it, i'll come back with my solution. 

Gábor


Gábor Bor
 

Thank you for the example Todd, i'll check it!

Best regards,
Gábor


Andreas Sedlmeier
 

You should start using tools, Todd ;). One tool which helps a lot with SOAP/REST/APIs anyways, although there's plenty of other good options meanwhile, is SOAP UI, which you can use to create mock services for testing your client applications. That's pretty easy basically (-> https://www.soapui.org/soap-mocking/service-mocking-overview.html) .

Happy new year!

Andreas 


Todd Baremore
 

Andreas,

I'm missing something.  How is recreating a 3rd party's web service easier than just working with the web service itself?
Frohes neues Jahr!
Todd
On 1/2/2019 2:43 AM, Andreas Sedlmeier wrote:

You should start using tools, Todd ;). One tool which helps a lot with SOAP/REST/APIs anyways, although there's plenty of other good options meanwhile, is SOAP UI, which you can use to create mock services for testing your client applications. That's pretty easy basically (-> https://www.soapui.org/soap-mocking/service-mocking-overview.html) .

Happy new year!

Andreas 


Andreas Sedlmeier
 

On Thu, Jan 3, 2019 at 12:24 AM, Todd Baremore wrote:
I'm missing something.  How is recreating a 3rd party's web service easier than just working with the web service itself
It's not easier, its just better. Most of the time even for most trivial APIs - and for more complex APIs I would say it's mandatory because only by mocking you then can test units of work and isolate problems resp. work around service dependencies for which you have your integration tests and where tools like the one I named help a lot too. Just google for advantages and benefits of unit testing and mocking to get tons of good documents.

For Magic development this is in my strong opinion even more important and relevant because the possibilities to refactor code in Magic (which often is needed to test units of work) are very limited in a tool where not even copy/paste of source code works reliable ^^.  Actually if you add a testing framework for Magic API clients you could even use that for the production version because Magic is a poor API client anyway where most of the required functionality is simply missing and has to be implemented "by feet" - where you elsewhere just work with annotations and dependency injection, ...

Its of course not a bad idea to suggest to Gabor to start with something easy, as you did, to get used to implement a REST (API) client. That was not the point anyways.

If he/she has however service definition files for the real API, the Mock services (and test clients) are generated automatically anyway and that's pretty easy then, you just have to get familiar with today's tooling and that's of course another issue. It's however mandatory too in my opionion if you do a lot with services, APIS, ...

Andreas


Gábor Bor
 

Hy Guys,

We got the solution. 

The WS provider sends us the code wich they use to call their own WS with Visual studio VB. One of my colleague made from that a dotNET code, we called an invoke .NET and wait the response in an Unicode Blob and it works fine.

Best regards,
Gábor