I need to make get requests from my Ktor server to another 3rd party rest api,
and from my app i will make request to my Ktor server.
How can i do that?
You need the ktor client for that.
The ktor client allows you to make requests and handle responses.
For more information and for an example you can look at ktor's documetation.
Related
I need to use an 3rd party rest api for my android app but this api requires me to use my own backend server.
So when i made a request from my app request will go to my ktor server and server should get data from another 3rd party api, how can i do that and what kinda structure should i use?
I usually prefer using ktor-client for this purposes, It is flexible, configurable and official package of ktor. I highly recommend it to you. Check the link.
I am fetching a GET API using the fetch command in react. When I run the production build, I can see the x-api-key in request header when I inspect in either Google/Firefox (network). This is the API key that my web app uses to make the request and I don't want it to get exposed in the browser's devtools. Any ideas on how to achieve this?
Fundamentally, you rewrite some stuff and proxy the request server side.
There is no way to hide the x-api-key header if you are directly making the request from the client. The only way is to make it from the server, then provide the results to the client.
I want to build my website like naukri.com (not exactly) but concept may match.
Currently I am writing API using jersey and consuming those API's directly from front end using AJAX request.
Do I need to write jersey client here as well, if so how that will help me out. Pls let me know, Why we need to write client if we are able to consume API's directly using ajax call.
You don't need a special client in order to interact with RESTful services. That's one of the main things that is appealing about them. There is no requirement to build anything with jersey client in order to host services with jersey.
You would build a client library if you want to make it easy for people to interact with your APIs from something an application. If this isn't something you need or want to do, you don't have to do it. Another use case would be for testing but there's no reason you have to build the client with jersey just because you built the server with jersey.
In your case you don't need jersey client, you already have client to call/consume API's at front-end i suppose, you will need jersey client if you want to call/consume your services at server-side to write test cases for example, something like this -
Client client = Client.create();
WebResource webResource = client
.resource("http://localhost:8080/RESTfulExample/rest/json/metallica/get");
ClientResponse response = webResource.accept("application/json")
.get(ClientResponse.class);
When a user register to my web application I send an email to verify his inbox.
In the email there are a link to a resource like this:
GET /verify/{token}
Since the resource is being updated behind the scenes, doesn't it break the RESTful approach?
How can I do it in a RESTful manner?
What you are talking about is not REST. REST is for machine to machine communication and not for human to machine communication. You can develop a 1st party REST client, which sends the activation to the REST service.
You can use your verification URI in the browser to access the REST client:
# user follows a hyperlink in the browser manually
GET example.com/client/v1/verify/{token}
# asking the client to verify the token
and after that the REST client will get the hyperlink for verification from the REST service and send the POST to the service in the background.
# the REST client follows the hyperlinks given by the service automatically
# the REST client can run either on the HTTP client or server side
GET example.com/api/v1
# getting the starting page of the REST service
# getting the hyperlink for verification
POST example.com/api/v1/verification {token}
# following the verification hyperlink
If you have a server side 1st party REST client, then the HTTP requests to the REST service will run completely on the server and you won't see anything about it in the browser. If you have a client side REST client, then you can send the POST in the browser with AJAX CORS or you can try to POST directly with a HTML form (not recommended). Anyways the activation should be a POST or a PUT.
It depends on what are you trying to do.
Does it fire an email after validating the user for example? If so, it is not an idempotent method and you should use POST.
Example:
POST /users/{id}/verify/{token}
If the method doesn't have any consequence besides the update, I think you should use PUT.
Aren't you overthinking REST? With e-mail verification you want the user to be able to simply click the link from whatever mail user agent he is using, so you'll end up with a simple GET on the server (presented as a hyperlink to the user) with the token either in the path or as part of the query string:
GET http://example.com/verify-email/TOKEN
GET http://example.com/verify-email?token=TOKEN
Either is fine for this use case. It is not really a resource you are getting or creating; just a trigger for some process on the backend.
Why do you think this would run afoul of good design?
Can anybody give me an example/link to build a JSONP web service client? I am trying to create a client to access a third party API to get some data which is working fine making a JSONP ajax call on the front end. I would like to move it to a servlet on the backend. Any help would be appreciated.
Thanks