I can create a new rating for a movie, but i'm having difficulties updating the ratings. What exactly is the ratingID? is it the numeric id for the movie? i.e. Charley Wilson's War has the numeric id: 70060021. so would the url to update the ratings be: http://api.netflix.com/users/userID/ratings/title/actual/70060021?rating=3? I can't get this to actually return anything. I've tried doing a PUT (like the documentation mentions) and also a POST.
Same question. I don't understand how we are supposed to know what a ratingId is.
Also, it is frustrating to be forced into knowing if a user rating already exists (i.e. have separate API calls for placing a new rating vs. altering an existing rating, and one doesn't work for the other).
You use the ratings/actual resource to determine if a rating already exists by passing the titleID in the titleRefs param. If the rating doesn't exist you POST to the same resource with the titleRef to create the ratings. If the rating does exist, use the returned ID and PUT to that ID with the new rating value. Agreed that it's a bit cumbersome, but it's completely in line with REST principles (POST on collection to create, PUT on item to update).
So, when I do what you recommended Michael, I get this returned in the <id></id> tag:
http://api.netflix.com/users/[my userId]/ratings/title/70060016
So, I've attempted a "PUT" request using this url:
/users/[my userId]/ratings/title/actual/http://api.netflix.com/users/[my userId]/ratings/title/70060016
with these "POST params" (I assume the only difference between POST and PUT is the request verb)
rating=4.
I get 0 bytes back as the response, and the rating does not change.
i've tried this as well (i've also tried to percent encode the ratingID) this still doesn't work. are we supposed to get a response back after a successful PUT?
I see where the confusion is occurring. I think the prototype URLs in the docs are confusing folks, since we have "ratings ID" at the end of the prototype. The whole URL is really the ID. Try PUT'ing to the ID itself, e.g. http://api.netflix.com/users/[my userId]/ratings/title/70060016.
I was concerned that aspect of the docs might throw people off. I think we'll swap out those prototypes with example URLs instead. Sorry for the confusion.
and you may not see the actual rating for it (because it's not been rated yet). You would just see the <predicted_rating>, not the <user_rating>
Then to do a POST
http://api.netflix.com/users/{userID}/ratings/title/actual?title_ref=http://api.netflix.com/titles/movies/70060021&rating=4&method=POST with the oauth params to set the rating.
You will get a response like below:
<status>
<status_code>..</status_code>
<message>Success, Your rating has been set</message>
<resources_created>
<ratings_item>
<user_rating>4.0</user_rating>
<id>
http://api.netflix.com/users/{userID}/ratings/title/actual/70060021
</id>
..
</ratings_item>
</resources_created>
</status>
In the above example you could grab the 'id' string and use it in the 'PUT' request like below to update the rating.
thanks a ton priya. It looks like the id returned e.g. http://api.netflix.com/users/[my userId]/ratings/title/70060016. doesn't actually have the /actual/ in the url. This was one of my problems; the other was not having the method=PUT parameter in the url.
Thanks for the explanation. I'm now attempting a PUT to this url:
http://api.netflix.com/users/[my userId]/ratings/title/70060016
with the HTTPBody of the request set to the data "rating=4".
When I make the request, I still get 0 bytes of data returned. I have successfully made calls for most all of the other API calls, but this one is giving me a lot of trouble.
Also, it seems like adherence to REST ideals shouldn't get in the way of a good interface. Users of the API probably will just want to be able to use a single request to rate all titles, instead of having to waste resources on these extra calls. The end result is the same, the movie will have the specified rating.
Ah. I finally got it to work. What I did was a "GET" (instead of "PUT") request with the two params you suggested priya. That, along with the "actual" that you have to add in made all the difference.
method=PUT is an HTTP method override for clients that can't set the HTTP method directly. It shouldn't be needed if you can set the HTTP method to POST. If you do that, the rating param needs to be in the request body vs. the URL as well.
Michael: "Agreed that it's a bit cumbersome, but it's completely in line with REST principles (POST on collection to create, PUT on item to update)."
It's not only cumbersome, but you've already doubled the chances of an error happening in a flakey mobile scenario. Could you consider adding a mechanism by which one could either add a rating if it isn't already there, or update it if it is?
You could still maintain 'REST'fulness if you simply redefine your domain so that a user *always* has a rating a set, just that one of the rating values is 'not set'. It's a bit cheeky, but it would be very valuable for clients who really have to care about every byte that gets sent.
Unknown
–
3 years ago
Bump.
I haven't heard back on this.
Note: it appears that you break 'restfulness' as well wrt to the 'no_opinion" setting. It appears that if the user sets that, then you treat the operation as a delete. i.e. the next time i query for a rating i get back nothing, *not* "no_opinion". As such, i think it would be acceptable to pretend that a user has a set rating for every movie. If they've never explicitly set it, then the default is simply "no_opinion". Deleting a rating would not actually delete it, but just revert it to that default. At that point, you'd never need to post, you could always 'put' a rating.
This would be highly beneficial as it would remove the need for any entire round of communication between the client and the server.
From our experience, removing a rating is not a very common action by netflix users, I'm not sure that us supporting this would really benefit your application that much.. I'm just thinking in terms of priorities, but this seems low in my radar personally..
I can create a new rating for a movie, but i'm having difficulties updating the ratings. What exactly is the ratingID? is it the numeric id for the movie? i.e. Charley Wilson's War has the numeric id: 70060021. so would the url to update the ratings be: http://api.netflix.com/users/userID/ratings/title/actual/70060021?rating=3? I can't get this to actually return anything. I've tried doing a PUT (like the documentation mentions) and also a POST.
Myron
Message edited by MoLo16 3 years ago
Brent – 3 years ago
Same question. I don't understand how we are supposed to know what a ratingId is.
Also, it is frustrating to be forced into knowing if a user rating already exists (i.e. have separate API calls for placing a new rating vs. altering an existing rating, and one doesn't work for the other).
Michael Hart – 3 years ago
You use the ratings/actual resource to determine if a rating already exists by passing the titleID in the titleRefs param. If the rating doesn't exist you POST to the same resource with the titleRef to create the ratings. If the rating does exist, use the returned ID and PUT to that ID with the new rating value. Agreed that it's a bit cumbersome, but it's completely in line with REST principles (POST on collection to create, PUT on item to update).
Brent – 3 years ago
So, when I do what you recommended Michael, I get this returned in the <id></id> tag:
http://api.netflix.com/users/[my userId]/ratings/title/70060016
So, I've attempted a "PUT" request using this url:
/users/[my userId]/ratings/title/actual/http://api.netflix.com/users/[my userId]/ratings/title/70060016
with these "POST params" (I assume the only difference between POST and PUT is the request verb)
rating=4.
I get 0 bytes back as the response, and the rating does not change.
MoLo16 – 3 years ago
i've tried this as well (i've also tried to percent encode the ratingID) this still doesn't work. are we supposed to get a response back after a successful PUT?
Michael Hart – 3 years ago
I see where the confusion is occurring. I think the prototype URLs in the docs are confusing folks, since we have "ratings ID" at the end of the prototype. The whole URL is really the ID. Try PUT'ing to the ID itself, e.g. http://api.netflix.com/users/[my userId]/ratings/title/70060016.
I was concerned that aspect of the docs might throw people off. I think we'll swap out those prototypes with example URLs instead. Sorry for the confusion.
priya – 3 years ago
In this case, you would do something like this.
Request the rating..
http://api.netflix.com/users/{userID}/ratings/title?title_refs=http://api.netflix.com/titles/movies/70060021
and you may not see the actual rating for it (because it's not been rated yet). You would just see the <predicted_rating>, not the <user_rating>
Then to do a POST
http://api.netflix.com/users/{userID}/ratings/title/actual?title_ref=http://api.netflix.com/titles/movies/70060021&rating=4&method=POST with the oauth params to set the rating.
You will get a response like below:
<status>
<status_code>..</status_code>
<message>Success, Your rating has been set</message>
<resources_created>
<ratings_item>
<user_rating>4.0</user_rating>
<id>
http://api.netflix.com/users/{userID}/ratings/title/actual/70060021
</id>
..
</ratings_item>
</resources_created>
</status>
In the above example you could grab the 'id' string and use it in the 'PUT' request like below to update the rating.
http://api.netflix.com/users/496140072/ratings/title/actual/70060016?method=PUT&rating=3
Hope this helps.
MoLo16 – 3 years ago
thanks a ton priya. It looks like the id returned e.g. http://api.netflix.com/users/[my userId]/ratings/title/70060016. doesn't actually have the /actual/ in the url. This was one of my problems; the other was not having the method=PUT parameter in the url.
everything looks like it works now.
Brent – 3 years ago
Thanks for the explanation. I'm now attempting a PUT to this url:
http://api.netflix.com/users/[my userId]/ratings/title/70060016
with the HTTPBody of the request set to the data "rating=4".
When I make the request, I still get 0 bytes of data returned. I have successfully made calls for most all of the other API calls, but this one is giving me a lot of trouble.
Also, it seems like adherence to REST ideals shouldn't get in the way of a good interface. Users of the API probably will just want to be able to use a single request to rate all titles, instead of having to waste resources on these extra calls. The end result is the same, the movie will have the specified rating.
priya – 3 years ago
Please try - http://api.netflix.com/users/[my userId]/ratings/title/actual/70060016. In your example, the string 'actual' is missing in the url.
Brent – 3 years ago
Hold on, how are you performing the PUT MoLo16? I don't understand why it would need to be a parameter if it is already the request verb.
Brent – 3 years ago
Ah. I finally got it to work. What I did was a "GET" (instead of "PUT") request with the two params you suggested priya. That, along with the "actual" that you have to add in made all the difference.
Brent – 3 years ago
Thanks a ton for the help.
Michael Hart – 3 years ago
method=PUT is an HTTP method override for clients that can't set the HTTP method directly. It shouldn't be needed if you can set the HTTP method to POST. If you do that, the rating param needs to be in the request body vs. the URL as well.
Cyrus Najmabadi – 3 years ago
Michael: "Agreed that it's a bit cumbersome, but it's completely in line with REST principles (POST on collection to create, PUT on item to update)."
It's not only cumbersome, but you've already doubled the chances of an error happening in a flakey mobile scenario. Could you consider adding a mechanism by which one could either add a rating if it isn't already there, or update it if it is?
You could still maintain 'REST'fulness if you simply redefine your domain so that a user *always* has a rating a set, just that one of the rating values is 'not set'. It's a bit cheeky, but it would be very valuable for clients who really have to care about every byte that gets sent.
Unknown – 3 years ago
Bump.
I haven't heard back on this.
Note: it appears that you break 'restfulness' as well wrt to the 'no_opinion" setting. It appears that if the user sets that, then you treat the operation as a delete. i.e. the next time i query for a rating i get back nothing, *not* "no_opinion". As such, i think it would be acceptable to pretend that a user has a set rating for every movie. If they've never explicitly set it, then the default is simply "no_opinion". Deleting a rating would not actually delete it, but just revert it to that default. At that point, you'd never need to post, you could always 'put' a rating.
This would be highly beneficial as it would remove the need for any entire round of communication between the client and the server.
Thanks!
mikey – 3 years ago
From our experience, removing a rating is not a very common action by netflix users, I'm not sure that us supporting this would really benefit your application that much.. I'm just thinking in terms of priorities, but this seems low in my radar personally..
=-mikey-=