A JavaScript client for consuming Axis2 service - javascript

I have written a service using Axis2. Now I wish to consume it using a browser based client written in JavaScript.

There are several options when deploying an Axis2 service, ranging from the webservice style (ex: RPC), encoding, transport (tcp/http), handlers, attachments, WS-Security, etc. which makes it hard or impossible to implement a fully compliant Axis2 client.
I would strongly recommend you publish your services enabling the REST api and consume the services via REST. Here's the link to the docs: http://ws.apache.org/axis2/1_5/rest-ws.html
If you want to take the hard route and parse soap messages, I would recommend that you write your client using GWT and expose some services using GWT exporter

Related

How to add a REST API to the Modern Web Dev Server?

I'm using the dev-server of Modern Web to build client side code.
Now I want to add a small backend with a REST API, but I can't find any information of how to add a backend with a REST API to this server.
Any hints on where to start?
You could write a plugin for it but I wouldn't recommend it.
It's a development server designed for testing client-side code.
It isn't designed to be a production server, and if you are going to write a REST API then you will, presumably, want it to be usable in a production environment.
Build your API with a tool designed for it (such as Express.js or Spring Boot) and use CORS to make it accessible to the server you use for client-side development.

access my backend node.js only from my app

I wanted to know how I can do that only my android application, developed with native react, can access my API node js. So my server will be accessible only from my site, using a simple whitelist of domains, and from my app
There is no way to guarantee this. A client controls everything that happens on client side. If an application contains protection mechanisms against client interference, it can be reverse-engineered.
A way to protect unauthorized clients from connecting to the backend is make backend requests with API key that is transmitted as encrypted (hashed) string and verified on server side. Abused API keys need to be blacklisted.
Since hashed keys can be extracted from API requests, a way to make this more complicated is to make hashed API key dependent on specific requests, e.g.:
fetchData(url + '&api_key_hash=' + md5(SALT + url + SECRET_API_KEY))
api_key_hash still can be verified on server side but is useless for a client who wants to get unauthorized access to backend API. The only way for a client is to get SECRET_API_KEY.
Since client application can be reverse-engineered to get unencrypted API key, a way to make reverse engineering more complicated is to not store the key as plain string and obfuscate the application.
Note that while these measures don't guarantee that the application won't be reverse-engineered to extract API key, obfuscation can complicate things for application developer, e.g. debugging and analyzing crash reports. To my knowledge, reverse engineering of React Native application that doesn't make use of any protection besides JS obfuscation is trivial.

How to use Vuforia Web Services API with JavaScript?

I've trying several things but nothing is really working. There are some examples in Vuforia Web Services API documentation using PHP but there's nothing with JavaScript.
It seems there's no Javascript API available for VWS. Even if it were, you will probably not be able to call it from web browser because of Cross domain policies.
That said, you can write your own back-end client in JS or run one of the samples in (Java/PHP/Python) in the server and expose all the methods as REST end-points.
VWS seems to be plain old REST services, which can be called from any language.
Only hurdle in writing your own simple client is to calculate signature for the requests, here's the logic to calculate signature from the documenation
Ref: https://library.vuforia.com/content/vuforia-library/en/articles/Training/Using-the-VWS-API.html
After you have the function for signature you will have to convert sample requests from the download for selected language to Javascript
These are the files in sample that I downloaded for Java, (https://github.com/christolb/MobEmbedded/tree/master/Pradeep/VWS%20Sample, it's uploaded by someone else on Github, I'm not adding it here myself, as I'm unsure of the licensing restrictions)
DeleteTarget.java
GetAllTargets.java
GetTarget.java
PostNewTarget.java
SignatureBuilder.java
Summary.java
TargetState.java
TargetStatusListener.java
TargetStatusPoller.java
UpdateTarget.java

REST Client: java backend consumer vs java script consumer

I want to generate webApp in java and just use some REST service. I think there are two approach for this:
1- Client side consumer: With an simple app that contain some java script file which call service and then generate UI from result.
2- Server side consumer: In backend first call service(with spring RestTemplate) then generate appropriate UI and send HTML ui to client.
Which approach is recommended?
I know this question is very general but I want to know advantage and disadvantage of those.
Client side consumer approach is the better one as tomorrow if you have one more client application who requires the same data but will be displaying it in a different way then client side consumer approach will benefit you. For eg: suppose the consumer today is a web page then you can get the data from backend and display it on your webpage, but tomorrow if your business grows and you plan for a mobile app then in that case your same rest api will come in handy for you.

BigQuery streaming data from site javaScript

I have a website and I want to send data (browser, page, etc.) into bigQuery.
How can I do this using only JavaScript?
You should check out the https://github.com/google/google-api-javascript-client Javascript library.
But the recommended way is to sent first to your backend then use your favorite language to send via REST forward to BigQuery. This would be much much more easier as you can use directly a service account to authenticate to the API. On the frontend the hassle is the OAUTH and obtaining and managing keys.

Categories