What's happened to the ID fields for groups and videos? The Simple API does give you ID's but the new API isn't, though you do get a URL field with what looks like an ID in it.
Seems you only get a url field now? Can that be used as an alternative?
In the v3 API, the IDs have been removed and instead the unique thing for each item is the URI. You should be able to use the whole URI to uniquely identify the items, but the ID shouldn't need to be extracted from them and presents a list of potential pitfalls since that's an unsupported use case.
Depending on your use case, there are different approaches that make sense for this:
If it's for managing your local cache, you can use the URI safely to uniquely identify the response.
If it's for forming subsequent requests, you will likely find them already formed for you in the metadata key for the response (inside either connections or interactions).
For finding the URI from a Vimeo video, we now include the URI inside the oEmbed response.
Related
I am trying to work with the Vimeo API and I cannot figure out how to access the ondemand data.
The endpoint and parameters in the docs require an ondemand_id to work correctly. I assumed this ID would come from any official ondemand page within Vimeo. But whenever I search the ondemand pages of Vimeo and click on a resource, the URL does not contain any numerical ID.
It only contains the root path for the Vimeo website with /ondemand_page_name at the end. This value cannot be the ID since it is a string and not a number. I have looked through the entire page plenty of different times to try to find the ID but cannot seem to find it.
For example, when you visit a normal video page on Vimeo, the URL looks something like this:
https://vimeo.com/272976101
where the number 272976101 is the video_id that can be used within the API to get all the data about this particular video. Instead of this format, the ondemand pages have the format:
https://vimeo.com/ondemand/nebula
where there is no numerical ID within the URL. This is the issue I am having. How would I retrieve the public data about this ondemand page throught the API.
I feel like there may be a very simple solution/explanation to this issue and any help would be much appreciated.
Also, right now I am not using any SDK to access this data. I am strictly trying to figure out how the API works through the built-in client provided within the documentation.
It's undocumented, but you can use the On Demand custom url path as the ondemand_id.
So for your On Demand video at https://vimeo.com/ondemand/nebula, you can make an API request to this path: https://api.vimeo.com/ondemand/pages/nebula.
In the response, you'll see the "uri" value "/ondemand/pages/203314", which you can log on your end and use as the ondemand_id instead of /nebula.
Also note, this should be the same URL as your On Demand settings page: https://vimeo.com/ondemand/203314/settings
I hope this information helps!
I am creating an API, which is going to list me products page by page with given filter conditions.
To give a brief description, it holds a AWS Lambda behind AWS API.
I am not able to decide whether to use GET or POST.
Because querying is considered a GET operation, so this is natural choice. But having a GET operation with JSON body is not very convenient way. So basically, I am left with the choice of putting it in URL.
About POST, I wont be able to use API cache in future if required.
Please suggest the right way.
Use GET.
Many clients do not support the body for GET, use URL params instead of the body. GET can be cached, bookmarked. Also GET is a natural choice as you are not updating any data.
Currently I set up a RESTful API backend using Django and I can list a set of articles by the following GET:
api/articles/
Also, I can get a single article by:
api/article/1/
Each article is owned by a certain user, and one user could have multiple articles of course.
On the frond end side, I present all the articles at loading of the page, and I hope the user who is logged in currently could see the articles that they own in a different style, e.g, outlined by a box, and has a associated "delete" or "edit" button.
This requires me to tell, after the retrieval of the articles, which ones are owned by the current user programmatically. One way of doing this is to check the current user id with the owner id. However I feel this is not a good choice as the user id is the check is done fully on the client side and may be not consistent with the actual server judgement.
Therefore, is there a way, to tell by looking at the response of the GET, (say, let the server return a property "editable=true/false") to get whether the current user could edit(PUT) the resource?
I understand that this could be done at the server side, by attaching such a property manually. However, I am just asking whether there is better/common practice.
I just started learning web development and I am sorry if the question sounds trivial. Thank you!
You can attach propriety manually as you suggested. The advance of this approach is that you dont need any other http request.
Second possibility might be, that your client intentionally request information about endpoint permissions. In this case I would suggest to use OPTIONS HTTP method. You send OPTIONS HTTP request to api/articles/1 and backend returns wanted info. This might be exactly what OPTIONS method and DRF metadata were made for.
http://www.django-rest-framework.org/api-guide/metadata/
I think that this is a very interesting question.
Several options that come to me:
You can add to the GET api/article/1 response a HTTP header with this information i.e. HTTP_METHODS_ALLOWED=PUT,PATH,DELETE. Doing this way helps the API client because it does not need to know anything else. I think that this is not a good approach when more than one entity is returned.
call to OPTIONS api/article/1. Allowed methods for that user on that resource can be returned but notice that, in my opinion, this approach is not very good in terms of performance, because it duplicates the number of requests to the server.
But what if the entity returned also contains information on the owner or it? can, in this case the client know which policy apply and try to figure out it by itself? notice that the policy can be obtained from another endpoint (just one call would be needed) or even with the login response. If your entities do not contain that kind of information, it could be also returned as a HTTP header (like first option above)
I have a web service to retrieve the list of my users : /users
My User entity has a lot of attributes (with many relationship such as roles, address, etc) and it begins to be painful to retrieve the whole list.
I want to create a new web service to retrieve a list of a minimal User DTO. This DTO contains only the username, the first name and the last name.
What's your suggestions for this new URI ?
/users-minimal
/users/minimal
/users/func/get-minimal
... ?
If what's changing is merely the representation, you should make that available as a different media-type, not a different URI. For instance, if you have application/vnd.mycompany.user.v1+json for a normal user, you could use application/vnd.mycompany.user-minimal.v1+json for the minimal.
Now, you probably don't use custom media types like the above, and if you are asking about RESTful URIs, you're probably not using HATEOAS either. For those REST-like HTTP APIs, you should probably use a querystring parameter instead. Something like /users?minimal=1 or /users/?fields=username,first_name,last_name.
I have perused the questions asked about this, but I still don't have a definitive answer.
I have an application and would like to build a RESTful API to expose a subset of information. I have three resources:
users
reports
photos
Users have reports and reports have photos. Photos cannot exist outside of reports and reports cannot exist outside of users.
I have designed the following URLs for my requirements
User login, server responds with token which is sent in the header of all API calls
GET example.com/api/
Get user info
GET example.com/api/users/{username}
Get all user reports
GET example.com/api/users/{username}/reports
Get all photos of a report
GET example.com/api/users/{username}/reports/{report_id}/photos
Add a photo
POST example.com/api/users/{username}/reports/{report_id}/photos
Delete a photo
DELETE example.com/api/users/{username}/reports/{report_id}/photos/{photo_id}
Modify photo description
PUT example.com/api/users/{username}/reports/{report_id}/photos/{photo_id}
Questions
Is it good practice to add a resource id in the URL, i.e. resource/id, or should this rather be added as a query parameter?
Is this method of chaining resources, i.e. resource/id/sub-resource/id/etc., acceptable and good or should I put all my resources at the top level and specify its position with query parameters?
Nothing wrong in this design.But this creates long URL which sometime are difficult to understand and the user of the API needs to know the hierarchy.Moreover the consumer of the API need to write more code in little bit non-standard way(Even though it can be done, but will be little messy). Think this from a different perspective
You have three resources and each has its own identity.So if we refactor the above URI's it will looks like below (I am demonstrating only GET)
User Resource:
Get users list
GET example.com/api/users
Get specific user
GET example.com/api/users/{username}
Report Resource:
Get all reports
GET example.com/api/reports
Get a specific report
GET example.com/api/reports/{report_id}
Photo Resources
All Photos
GET example.com/api/photos
Specific Photo
GET example.com/api/photos/{photo_id}
User All Reports
GET example.com/api/reports?username={userName}
Specific report of a user
GET example.com/api/report?username={userName}&report_id={reportId}
User All Photos
GET example.com/api/photos?username={userName}
User All Photos for a report id (You may not need user Name if report_id is unique irrespective of the user, which will further simplify the URI)
GET example.com/api/photos?username={userName}&report_id={reportId}
All photos of a report
GET example.com/api/photos?report_id={reportId}
This simplifies the understanding and more standard code can be written on the consumer side using this approach.
IMHO you are modelling it well.
Regarding 1 I'd rather go with resource/id rather than query param. But one thing you must have in mind when modelling is the cache mechanism by proxy and so on. So do not forget the headers.
I go for query params for filtering and those sorts.
About the login, the credentials should be in the headers, and no specific resource is needed. Just apply per resource security.
I don't see anything wrong with your scheme.
Most frameworks nowadays use a similar standard for specifying url's (like Django).
In my personal opinion, it makes the URL more readable and a bit nicer for the user.