I am writing a ruby client for the REST API using RestClient gem. While going through examples, I see different code used to achieve basically the same result, without any explanation on the difference.
client = RestClient::Resource.new('https://example.com/')
response = client.get
VS
response = RestClient.get('https://example.com/')
What is the benefit of using Resource class, if I can achieve same thing with get method?
Code reuse. It's especially useful when you're dealing with APIs, and you need to hit the same base urls over and over, with different params and/or paths. As the docs show you, once you build a base resource:
client = RestClient::Resource.new('https://example.com/')
You can access other paths under this resource quite easily:
response = client["/users/1"].get
Which is equivalent to
response = RestClient.get("https://example.com/users/1")
but less typing/repetition.
Related
I am using a Spring REST template to pull data using POST and everything is working fine.
ResponseEntity<MyObject> resp= restTemplate.postForEntity("url", inputParam, MyObject.class);
But now since I am not doing any POST operation, I want to change it to GET. I can do this by adding all input params as url parameters and do:
ResponseEntity<MyObject> resp= restTemplate.getForEntity("url",MyObject.class);
But the problem is, inputParam has alot of parameters, so preparing the url manually is not the best solution. Also GET requests have length restrictions.
Is there any other better solution for handling this?
First of all, I think your second line should say getForEntity().
Secondly, there are numerous URL builder class options if you google around (including ones from Spring). So, I would use a URL building class to prepare the URL rather than manually doing it yourself which can get messy.
https://www.baeldung.com/spring-uricomponentsbuilder
https://square.github.io/okhttp/3.x/okhttp/okhttp3/HttpUrl.html
https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/UriBuilder.html
Length Restriction
There's a good SO entry here noting length restrictions of common browsers; so if its going through a browser then I'd stick to POST if you're potentially over the 2000 lower limit they suggest.
Technically there shouldn't be a limit according to https://www.w3.org/2001/tag/doc/get7#myths.
I think on a lot of back-end technologies there is no limit. So, if this is API-only and not going through a browser (like back-end to back-end) then you may be able to ignore those limits. I'd recommend looking into that specifically though and testing it with your back-end.
UniRest
Also, as a personal recommendation, I have found UniRest to be an amazingly useful REST client which makes most of my code much cleaner :). If you have time, maybe try giving that a shot.
http://unirest.io/java.html
Is there an easy way to ask the google api ruby client to just give you back the stock HTTP response, rather than to perform the lovely, but slightly limiting translation into one of their ruby representable objects?
e.g.
response = Gmail.client.get_user_message("me", id)
=> #<Google::Apis::GmailV1::Message
response = Gmail.client.list_user_messages("me")
=> #<Google::Apis::GmailV1::ListMessagesResponse
but
response = Gmail.client.delete_user_message("me", id)
=>nil #successfully deleted
Now that's all fine and dandy, except that sometimes I just want to know what sort of response is going to come back. i.e. an HTTP response with maybe some JSON in the body. And then I'll worry about what I do with it...
I can take the response and use the
response.to_json
to get the body of the json that would have come back (though I still won't have the response code, and I need to KNOW that it's one of those objects first).
The client library is definitely getting that, it's just converting it into these objects before it lets me see it. And if I don't know that it's a google object (and not nil) I can't run that to_json consistently....
Any ideas other than second guess what google is going to send me back?
(I should note that this has come about when trying to move a library from dealing with their 0.8 api to their 0.9 api, so call me a cynic if you must but my faith that google won't make breaking changes to those objects returned is at a low ebb...
As far as I know, it is possible to ask the server to send only the fields you really need and get a partial response instead of the default full response as mentioned in Performance Tips.
However, I suggest that you please check the documentation for the specific API you are using to see if the field you're looking for is currently supported. For the Gmail API, you may go through Working with partial resources.
Here are the two types of partial requests that you can use:
Partial response: A request where you specify which fields to include in the response (use the fields request parameter).
Patch: An update request where you send only the fields you want to change (use the PATCH HTTP verb).
Hope that helps!
I have a model say TestModel as follows:
class TestModel(models.Model):
name = models.CharField()
description = models.TextField()
Now I can use a ModelForm to save data to this model. However, say I want to use Ajax and send a url as follows savethis?name=ABC&desc=SomeRandomDescription to a view that handles it as follows:
def savethis(request):
if request.GET['name'] and request.GET['desc']:
name = request.GET['name']
desc = request.GET['desc']
test = TestModel(name=name, description=desc)
test.save
return HttpResponse('Ok')
else:
return HttpResponse('Fail')
What's to stop someone from running a script that can easily hit this url with valid data and thus save data to my model? How do I ensure that incoming data is sent only from the right source?
One option is sending the data as JSON in a Post request but even that's not too hard to emualte.
Seems that you have stumbled upon the great security flaw that is Cross-site Scripting attacks. They are several ways you can get around it, but going into all of them in one answer would be fruitless. I suggest you Google the term and do some poking around, and you will find several different methods on how to protect your site better.
Django has a security page dedicated to talking about how to protect your site.
I'm implementing a simple tumblr api tool for my girlfriend, and I'm having some trouble working with the data handed to me by Tumblr.
The structure handed back can be found here (scroll down a little for the example.)
The following string of hash keys works while I'm working manually in IRB:
followers_result['response']['users']
But when I launch the server and try to walk the json hash, I get a "Can't convert string to integer" typeerror. Using the following code, response['users'] is identified as the problem field. (I expanded the hashtree query a bit here.)
followers_result = JSON.parse(#followers_response.body)
response = followers_result['response']
users = response['users']
users.each do |follower|
followers << follower['name']
end
I'm having the same problem with my other request, which requires a few more nodes down the tree... Anyone know why this would be different between server and irb?
(One difference is that the server is requesting via OAuth whereas my irb tests are requesting via net/http, but I'm taking the exact same OAuth query and adding my API key on to do the tests with. I'm not sure how to manually request it via OAuth to make sure that the server is getting the same document because of the three-legged authentication.)
Thanks for any help/suggestions,
Cameron
I am trying to make a RESTful api and have some function which needs credentials. For example say I'm writing a function which finds all nearby places within a certain radius, but only authorised users can use it.
One way to do it is to send it all using GET like so:
http://myapi.heroku.com/getNearbyPlaces?lon=12.343523&lat=56.123533&radius=30&username=john&password=blabla123
but obviously that's the worst possible way to do it.
Is it possible to instead move the username and password fields and embed them as POST variables over SSL, so the URL will only look like so:
https://myapi.heroku.com/getNearbyPlaces?lon=12.343523&lat=56.123533&radius=30
and the credentials will be sent encrypted.
How would I then in Sinatra and Ruby properly get at the GET and POST variables? Is this The Right Way To Do It? If not why not?
If you are really trying to create a restful API instead if some URL endpoints which happen to speak some HTTP dialect, you should stick to GET. It's even again in your path, so you seem to be pretty sure it's a get.
Instead of trying to hide the username and password in GET or POST parameters, you should instead use Basic authentication, which was invented especially for that purpose and is universally available in clients (and is available using convenience methods in Sinatra).
Also, if you are trying to use REST, you should embrace the concept of resources and resoiurce collections (which is implied by the R and E of REST). So you have a single URL like http://myapi.heroku.com/NearbyPlaces. If you GET there, you gather information about that resource, if you POST, you create a new resource, if you PUT yopu update n existing resource and if you DELETE, well, you delete it. What you should do before is th structure your object space into these resources and design your API around it.
Possibly, you could have a resource collection at http://myapi.heroku.com/places. Each place as a resource has a unique URL like http://myapi.heroku.com/places/123. New polaces can be created by POSTing to http://myapi.heroku.com/places. And nearby places could be gathered by GETing http://myapi.heroku.com/places/nearby?lon=12.343523&lat=56.123533&radius=30. hat call could return an Array or URLs to nearby places, e.g.
[
"http://myapi.heroku.com/places/123",
"http://myapi.heroku.com/places/17",
"http://myapi.heroku.com/places/42"
]
If you want to be truly discoverable, you might also embrace HATEOAS which constraints REST smentics in a way to allows API clients to "browse" through the API as a user with a browser would do. To allow this, you use Hyperlink inside your API which point to other resources, kind of like in the example above.
The params that are part of the url (namely lon, lat and radius) are known as query parameters, the user and password information that you want to send in your form are known as form parameters. In Sinatra both of these type of parameters are made available in the params hash of a controller.
So in Sinatra you would be able to access your lon parameter as params[:lon] and the user parameter as params[:user].
I suggest using basic or digest authentication and a plain GET request. In other words, your request should be "GET /places?lat=x&lon=x&radius=x" and you should let HTTP handle the authentication. If I understand your situation correctly, this is the ideal approach and will certainly be the most RESTful solution.
As an aside, your URI could be improved. Having verbs ("get") and query-like adjectives ("nearby") in your resource names is not really appropriate. In general, resources should be nouns (ie. "places", "person", "books"). See the example request I wrote above; "get" is redundant because you are using a GET request and "nearby" is redundant because you are already querying by location.