Is it possible to create a photo collection using the flickr API?
I haven't found any example code to achieve this, however you CAN do it on the flickr website, and i suppose flickr uses the API internally for their site?
Dennis
This may be too late to help but, I thought I'd post the solution here for posterity (as this post came up while i was google'ing for the answer before i discovered it).
The method is undocumented in the Flickr API but, it does seem to work (tested via the REST interface).
The method is: flickr.collections.create
Required parameters:
auth_token
api_sig
title (Example value: "My Awesome Title Here.")
Optional parameters:
api_key
auth_hash
cb
description (Example value: "My Awesome Description Here")
parent_id (Example Value: 0)
src (Example: "js")
I found the method by enabling Firebug's console while creating a collection in the Flickr web interface and examining the POST. I have no idea what auth_hash nor cb refer to but, I would assume that they are required while using the JavaScript interface as opposed to REST.
Anything that uses the JavaScript interface on Flickr can be reverse engineered by examining the POST that occurs immediately after you take the action in the web interface.
Official support for the "flickr.collections.*" portion of the Flickr API has indeed been delayed for some reason (since at least 4/2007). There is a discussion thread over on Flickr, with a bit more information (reverse engineering) on the undocumented API.
Yes, you can. But, first you need to specify so-called 'primary photo'.
This means that flickr doesn't allow you to create empty albums (collections). I don't know why they decided to restrict creation of empty collections but it's a fact.
Related
Here is an excerpt from an assignment I am currently doing:
Build a dummy app that:
Contains a REST API that operates over a single resource.
Contains a Backbone client that consumes that API and can list, show, create, update, and remove that resource.
My understanding was that the term "consume" implies total coverage of the API's exposed ressources. However, the assignment says "consumes that API and can [CRUD] that resource".
Is that sentence redundant or is my understanding of the term wrong?
(Bonus question: why searching Google for this question returns countless language-specific tutorials for "consuming an API" but none explain what the term actually means?).
To consume an API means to basically use any part of it from your application.
Consuming an API here means creating a client which can send requests to the API that you build.
It appears that you need to create and API which can handle Create, retrieve, update and delete (CRUD) of a resource. For instance if your REST api is to create a blog, your API should handle CRUD functions for the object/resource blogpost.
POST - Create a blog post
GET - Retrieve a blog post
PUT - Update a blog post
DELETE - Delete a blog post.
It is about the direction of the app's interaction with API - it either provides an API, or consumes it, so there are providers and consumers of API, and this is just a less general and ambiguous term than 'using'.
Simply consuming an API means using it in your application.
For, e.g., GET request to https://someapi/Users will give you all the users.
You need to request this URL https://someapi/Users to get all the users and then you can use it into your application.
I always think about Albert Einstein's quote of "If you can’t explain it to a six year old, you don’t understand it yourself." when someone asks a question that you might take for granted due to technical experience you have on a subject.
I think the following medium.com article does an excellent job explaining it: How do you explain API to a 5-year-old?
simply means : using the API.
You can do it with HTTP method (GET, POST, PUT, DELETE..) using something like Postman (Tool) or maybe you have a client app/library that calls these methods implicitly.
I want to show my customer's flickr page using API.But i don't know which method is used to take the photos which are shown in our home page of flickr.
Thank you
I think you are looking for this API function: https://secure.flickr.com/services/api/flickr.people.getPhotos.html
(Note that probably you could also call
https://secure.flickr.com/services/api/flickr.photos.search.html
setting the parameter user_id (Optional) to the id of your customer's flickr page.)
One way to do this is by using Temboo - a service that makes it easy to work with lots of APIs in the programming language of your choice.
Temboo has a method called ListPublicPhotos that is built on top of the Flickr API. You pass it a Flickr API key and the ID of your customer, and it'll return their public photos in JSON format.
You can experiment with this method in your browser and then automatically generate the source code you need to call this behavior from your code.
(Full disclosure: I work at Temboo, so let me know if you have any questions!)
I'm trying to post an image on Tumblr using OAuth. I'm using Objective C, but a general solution would be very helpful as well.
I manage to post an image that is online (using the "source" parameter). However, I can't post an image from the client (using the "data" parameter), and some issues confuse me.
1) Should I use "multipart/form-data" or "application/x-www-form-urlencoded"? I've seen conflicting claims on this issue.
2) What should I put in my post body and what should I put in my basestring? According to the oAuth specifications, if I use "multipart/form-data" then I don't need to add the parameters that I add to the post body (like "type" and "caption") to the base string, but even when I succeeded posting with "source", it only worked if I added the parameters to the base string as well.
3) In what format should I add the image to the body? If I need to also add it to the base string, then in what format should I add it there?
Thanks!
The problem with Tumblr is "unusual" implementation of OAuth (OAuth issues). It's not likely to be possible with "old" OAuth (from code.google.com/p/oauth/). I myself ended up using one of these solutions: crossbreeding OAuth with ASIFormDataRequest, but it is not likely to work with multiple images, or integrating TumblrUploadr. Also, Tumblr is likely to work better with new OAuth library (from here)
, but it will definitely conflict with ShareKit if you use it.
Concerning your questions:
TumblrUploadr uses application/x-www-form-urlencoded so it
is likely to be this one.
With any of solutions above, you should
just pass UIImageJPEGRepresentation of your image. TumblrUploadr has
it's own URL-encoding and for ASIFormDataRequest, I'm not sure.
URL-encoded binary data, as it is said in Tumblr API. I myself
didn't investigate ASIFormDataRequest deeply, so I'm not sure if you
need to add it to base string.
Is there a way to get a list of related artists through the spotify api. Like the small list that displays in the actual program?
Would be very useful if so, but I am not so sure
Cheers
Yes, it's available through libspotify. There's a SPArtistBrowse class that contains a lot of metadata, including the related artists. Check out the
CocoaLibSpotify comes with a documentation package, where you can find more details on what's included: https://github.com/spotify/cocoalibspotify.
Do note that it's currently extremely slow to load an entire SPArtistBrowse object. I'm assuming it's got something to do with libspotify loading it all in one chunk and on the main thread (?). From what I know, Spotify are suppose to remedy that in an upcoming version of libspotify, though.
Get an artist's related artists is now available through the Spotify Web API.
GET https://api.spotify.com/v1/artists/{id}/related-artists is the format.
https://api.spotify.com/v1/artists/43ZHCT0cAZBISjO8DG9PnE/related-artists is an example request.
For more information, see the API documentation.
There is also a JSFiddle demo app.
Definitely! All you need is the "artist_id" and the SpotifyPublicAPI can return a list of the related artists. You don't need an access_token at all.
You can easily test the API call here on RapidAPI. I've specifically linked you to the getArtistsRelatedArtists endpoint. Rapid will provide you with a code snippet you can copy and paste directly into your code to make the call.
Here is an example testing the API call using Beyonce's artist_id:
Here is a sample code snippet provided by RapidAPI wth Beyonce's artist_id passed as a parameter:
I would like to know if there is some best practices about the root endpoint for a REST web service? I mean, should it be a short documentation about the usage of the API itself? Should it be an XML document describing all methods available? Should it only return "unknown method"?
The question is perfectly clear to me.
I think it should respond with 404. If there is no resource associated with the root path, then there is nothing to return.
If you feel that 404 is not helpful, then it would also be OK to return the URL of the documentation.
REST is supposed to be self describing so having the root show an error is poor design in my opinion.
I like the root to contain information that allows you to navigate the rest of the API.
So for example the root might contain a link to a list of product categories from which the API user can select a category and then a list of products etc.
A self describing API means less documentation to write and keep updated!!
NerdDinner.com1
The Sun Cloud API
Twitter
Paul Jame's article
MediaWiki's API2
1. NerdDinner uses WCF Data Services, which is a great way to correctly implement RESTful services. The reason I am point to that, and not WCF data services directly is because it is a public website and you can use it.
2. MediaWiki is not a great example because they are passing actions in the URI but it is technically a RESTful service and show's a lot of interesting ideas.
This question as asked is unclear. I would guess it means something like a directory that all API methods are under. For example, the root directory of the Flickr API would be http://api.flickr.com/services/rest/.
For an example of a project that accesses the Flickr API, see python-flickrapi
the rootend point of REST API is the the API defined for the first slash i.e "/" of the url after the dispatcher-servlet. It contains all the GET for the list of resources (mostly the get for all the database tables) this list further contains all the items and in single item there will be DELETE , PUT/PATCH and SELF get URL. Thus making the implementation of HATEOS.
For me, I just redirect to my frontend.
In node JS, use res.redirect("https://<<your frontend>>");