I am using this API Function
https://developers.cryptoapis.io/technical-documentation/wallet-as-a-service/transactions/create-coins-transaction-from-address-for-whole-amount
And a NodeJS back end with an Angular Front end.
I cannot figure out how the Callback in that functions POST works, It requires a domain setup and then for a JS function to take the post in but I cannot figure out how to do that.
Could someone please advise how to work with an API callback function like that
it looks like you would need a route on your NodeJS server that this service ( cryptoAPI ) could call - so like (needs to be HTTPS) https://yourDomainTheApiIsHostedOn.com/callBack
The documentation does say it will only fire when the create coins function is called. The call back URL also will have some info so you can verify the HTTP traffic is really from them
The callbackSecretKey can only be generated by the customer. It is used to create a unique hash string in the x-signature response header in the callback request sent from Crypto APIs 2.0 when the event occurs.
The domain verification is basically a process for cryptoAPI to ensure that you own that domain which is hosting your API
Documentation is here:
https://developers.cryptoapis.io/technical-documentation/general-information/callbacks#callback-security
Related
I have nestjs application running on typescript, Graphql, Postgres with Jwt strategy defined, now I need to workout LinkedIn strategy with it. I am not really sure where to start with it, there are a couple of packages available but they are missing the Graphql part and they are mostly pointing to API endpoints on local like /auth/linkedin/callback, I would like to know here and how to start.
If you look at LinkedIn's OAuth documentatioin you'll see that LinkedIn needs to know about a callback url for when authorization attempts are successful. You'll also see that the response for the initial authroization call (what calls your callback URL) is a GET request that doesn't conform to GraphQL format, so you have to implement a REST endpoint for this.
This is pretty true for most OAuth2.0 calls. You need to implement them in REST, not GraphQL. If you really wanted to, you could take the REST call and do some transformation to make it a GQL call, then forward it on to your GQL server, but that's still a REST endpoint you've got in your server.
I am currently running a web service on an Apache Tomcat servlet container. The web service has a base URL and exposes my applications data using the following structure:
http://[hostname]:[port]/path/to/root/[db_table_name]/[primary_key]?fields=name,...
An HTTP GET call to a URL like the one above would return a JSON formatted string.
Though the documentation for my application describes this as a RESTful API, I am confused because I was under the impression that true RESTful APIs do not use query strings. Rather, as I understand it, a true restful API provides a uniform structure, in the form of resource endpoints.
My questions relate to how I can create a custom API to leverage the existing API using Node.js. I do not want to rewrite the application logic or database calls; I just need to know how I can create the API calls using Node.js (possibly using Express or some other framework) and let the existing API handle the request.
For example, I could write Node.js code using the Express module that has several routes, these routes would handle client requests that in turn would call the existing API (i.e. /path/to/root/[table_name]/[pk]... and return the response.
If my Apache Tomcat server is listening on port 8080, how would I deploy my Node.js server to listen on another port and then redirect requests to the existing WS URL on port 8080.
Does the Express framework support explicitly specifying a root path (such as http://localhost:3000/path/to/root/[table_name]/[pk]) as the default root path?
Finally, I know REST APIs support CRUD operations. In the case of a POST method, does Express (or Node.js) have built-in logic to handle duplicate POST requests so that duplicate records don't get created in the database.
I'm reading through different article and tutorials on REST but I think I'm missing something. Any information or advice that can take me in the right direction would be much appreciated.
there's a lot to cover here but I'll try to cover your three questions. Since you have mentioned using Express I will answer assuming that Express is the framework you are using.
If you are using Express, you can choose which port to listen to when you start the server, so you can choose any port that you like at that point (see here).
If you need to redirect a request you can do so easily with res.redirect() (see here). However, you could also call the other web service directly, retrieve the data and return it to the client instead of redirecting them if you prefer. That would require some more code to make the http requests in node.js though.
I am not 100% sure if this is the answer to your question, but there are ways to add a "base path" or namespace to all of your routes. I found this example where various namespaces are used but in your case you only need one which applies to all routes.
I don't think there is a built-in way to do this. The best I can think of is potentially creating some kind of ID for the request so that if it is sent twice you could use this to check but it's far from ideal.
I would like to add that I'm not sure where the idea that query parameters not being RESTful comes from? I think query parameters are fine because that is how you query! Otherwise you couldn't ask for the right data from your RESTful API. Let's say you have a /posts endpoint and you want to get the posts of a particular user (user ID = 1). The RESTful way to do this would be to issue a GET request to /posts?user=1.
Hope this helps!
I’m planning some changes to how users interact with the data served on the front end of my web app.
This app streams news feeds from twitter. Currently the front end built with angular sends an http request that is passed to a route in my node backend. The backend uses the Twitter api to load the response. As my user base grows though the requests will be too expensive to maintain. Instead I want my backed to use a timer and make a Twitter api request, Store the data in a variable and then serve that data to the user on the front end.
What would be the method for me to do that?
Backend:
1. Node http.request to Twitter API using timer
2. Seperate route that handles the incoming request from the angular front end.
Front end:
3. Http request from front end that sends the request to the route (2) in the backend.
I thought I could use promises but i’m now sure how chaining would work here.
For your backend server I'd suggest to create an API cache with Redis to optimize the performance, due to less information about your code, I can help you with an example to create your own one by implementing it with your Angular and node due:
https://www.compose.com/articles/api-caching-with-redis-and-nodejs/
hope it help you!
I have been using the asynchronous abilities of Node.js from quite some time now. But I am stuck on an interesting problem. Basically I have 2 API's that I need to call one after the other. Due to the asynchronous nature of Node.js I cannot retrieve the response of the first API request till it has finished and the respective callback function is called.
What I want to do is that I want to pass the response from the first API as request payload to the second API on the fly and not wait till the first API gets fully completed.
As a possible alternative, should I switch from building rest API to stream APIs?
Any pointers on how to do this?
Thanks
Yes, converting REST API'S to stream API is a better option. Node.js is known for its asynchronous behaviour. Because of the same all REST api's function in the same manner as you described earlier. As someone has previously pointed you could look at the Twitter Stream API for reference.
For more understanding you can check out this link - How to create a streaming API with NodeJS
Question
A NodeJS server is called by a client. This causes a further call to be made to a 3rd party API. The API then asynchronously calls-back to the NodeJS server. How do I make the client aware that the asynchronous callback has completed?
Details
I have an NodeJS server with these two routes (code is coffeescript):
app.get '/security/login/application/authorise', ->
applicationService.authorise()
app.get '/security/login/application/callback', (req, res) ->
applicationService.login req, res
The first route is called by my AngularJS client. Its purpose is to authorise the client and allow it to start-up (users will sign in later). The authorisation process involves making a call to a third party security API.
The security API does its thing and then calls-back to the NodeJS server via the /callback route shown above. The information passed to the callback allows a further call to be made to the API that determines if the original authorisation request will pass or failed.
The problem is that call to the first call to the /authorise route is, of course, asynchronous and so returns to the client right away. The client is then left in limbo, not sure if the NodeJS server has authorised it or not.
Please note that I cannot just nest these calls (imo) because the first call to the API simply returns 200 OK regardless. The process only continues when, sometime in the future, the third party API starts a new conversation by calling back into the NodeJS server via the /callback route.
Options
It seems I have a number of unpalatable options:
Stay Asynchronous. Return control to the client and then have the client poll the server, presumably with some unique, temporary 'callback-id', to determine if the callback has been completed.
Go Synchronous. Block the return with a hacky loop of some sort. Maybe promises can clean this up a bit somehow.
Go Bidirectional. Use sockets to allow a push notification from the server (but what about old browsers like IE8, which I have to support).
I think I have probably over-cooked this problem and the solution is most likely easier than I imagine. Your help would be gratefully received.