Can someone explain to me in, in REST terms, Twitter's design decision with the parameter placement in these two calls? It seems that the :id placement is inconsistent and arbitrary (although clearly this was deliberate).
GET statuses/:id/retweeted_by
Show user objects of up to 100 members who retweeted the status.
GET statuses/retweets/:id
Returns up to 100 of the first retweets of a given tweet.
There are other similar examples throughout their API (https://dev.twitter.com/docs/api), so I'm definitely missing something.
Thanks!
Just making guesses here
Someone at Twitter once pointed out that the Twitter API runs on several servlets. I can only assume that this was related - it's easier to map /retweets/* than to map every single combination.
Update: I think that the history of the API itself can also be relevant. Twitter's API hasn't really changed much over the past years, and if it did change then it would be because new features would be added. An endpoint like GET statuses/show/:id is old, while GET statuses/retweets/:id is newer. If Twitter at some point decided to change naming conventions, they couldn't just rename the old ones, since it would break applications.
Another theory of mine is that GET statuses/retweets/:id actually doesn't refer to the Tweet :id itself, but is about the tweets that were based on it. GET statuses/:id/retweeted_by is directly related to the tweet itself, by returning users and not other statuses.
I too am often puzzled by the naming consistency. I'm sure they have their reasons though.
I ended up checking with a friend at Twitter, who says:
"I just talked with the guy who originally wrote those two API
endpoints, and he doesn't remember why. To answer your question,
though, there probably isn't a good RESTful reason for that design."
Related
I'm trying to generate multiple related hashtags based on the keyword entered by the user. For example: if the user has typed 'meme', it would generate multiples hashtags related to it (memes, funny memes)
I looked for an Instagram API but didn't find any such endpoints. There are lots of sites and apps available over this thing. Can anyone suggest to me how this would work? I'm not expecting you to do work for me. Just need your guidance on this? Is there any way to achieve this?
https://developers.facebook.com/docs/instagram-api/guides/hashtag-search/ (I goes over all the endpoint but didn't find it, is there any other way to achieve it?)
Demo:- https://toolzu.com/hashtag-generator-for-instagram/ (this brings related hashtags, difficulty and number of times each hashtag has been used)
This api returns hashtags related to a keyword. It's easy to use with axios. Downside is a the limited number of free calls
hashtag api: https://rapidapi.com/miguel.aka.kelter/api/hashtagy-generate-hashtags/
Good luck
I am trying to get as much data as a I can out of the Twitter API for an academic research project. Even though I only have access to the Standard API the data should be as accurate as possible. I am building myself a "wrapper" around Twarc and other utilities in Python that gets me most of the data I want in just the format I need. A big problem was getting all the replies, but I was able to solve it with a bit of trickery: Searching from the tweet in question onwards and then checking if the tweets in the obtained sample have the original tweet ID in "in_reply_to_tweet_id". Rinse and repeat with those newly obtained tweets.
Then I noticed the new moderation feature Twitter implemented in March. Now the moderated comments under "More replies" do not show up in my search output.
Example: https://twitter.com/NDRreporter/status/1113353224730365952
I find all replies except the following: Under "More replies" ("Mehr Antworten" in German), there is a reply chain started by a extreme right leaning (possibly troll) account ("#Der Steuerzahler") that got moderated and shoved down there. This does not show up in API searches, even if I let the code iterate for over an hour just looking for replies to this particular original tweet.
My question is pretty general: Aside from getting replies as they come in (i.e. before they are moderated) via Filter API, is it possible to find these moderated tweets via the Standard Search API? Not looking for a ready-made solution, general pointers suffice. If I can't find them via Search, then I obviously won't try it with that anymore.
Thanks in advance.
Using the Souncloud API, I'd like to retrieve the reposted tracks from my activities. The /me/activities endpoint seems suited for this and I tried the different types provided.
However, I didn't find out how to get that data. Does anyone know?
Replace User Id, limit and offset with what you need:
https://api-v2.soundcloud.com/profile/soundcloud:users:41691970?limit=50&offset=0
You could try the following approach:
Get the users that shared a track via /tracks/{id}/shared-to/users endpoint.
Fetch the tracks postet by this user via /tracks endpoint, as the _user_id_ is contained.
Compare the tracks metadata with the one you originally posted.
I am not into the Soundcloud API, but taking a close look at it seems to make this approach at least as technical possible, though e.g. fetching all tracks won't be a production solution, of course. It's more a hint. Perhaps reposting means something totally different in this context.
And the specified entpoint exists in the general api doc, so I don't know if you would have to extend the java-api-wrapper for using it.
I am curious as to how a CRUD REST API would implement the idea of a tweets resource. Of course, an application such as Twitter has the notion of tweet objects, but these are needed by the application in various ways ("collections").
Twitter would need an endpoint for user timeline (tweets published by a certain user) and also for the home timeline (the timeline of tweets from people a user is following). I imagine, in a CRUD API, user timeline would be located at a URI such as: tweets?filter={username:"Bob"}
However, I'm not quite sure how a CRUD API design would implement the home timeline collection of tweets. Furthermore, collections such as favourites for a user — are these treated as separate resources altogether, or should they somehow be attached to the tweets resource?
Furthermore, Twitter have not used the CRUD design for their API. Maybe there is a good reason for this?
The good thing about resource design is that it doesn't really matter, as long as it makes (some) sense. Obviously some nuances are in place, but let's get to the point. Business models don't (have to) map 1:1 to resources, this is probably why you don't find such relation in the Twitter API.
Some assumptions: Timelines are pre-defined and their behaviour isn't influenceable, other by creating new tweets. Favorites are (references to) tweets. Favorites are influenceable.
A favorite collection resource, could be something like:
/user/bob/favorites
Your "CRUD" operations could be something like:
[POST] /user/bob/favorite { "tweet_id": "343fe4a" } -- Add a new favorite
[GET] /user/bob/favorite -- All favorites, for the user Bob
[DELETE] /user/bob/favorite/343fe4a -- Delete tweet 343fe4a as being favorite
Normally it's best to avoid multiple variables in a single resource, as this introduces a certain complexity that isn't needed. In this example, however, a favorite doesn't have it's own identifier. It instead re-uses the identifier from a tweet and it's also tightly-coupled with a user.
If a favorite does have it's own identifier, I would go about creating a resource like: /favorite/ef213e13f this could return meta-data or act as an alias (redirect) to a tweet for a HTTP GET method or a resource to "un-favorite" something (DELETE method).
This statement probably makes more sense if we don't talk about tweets, but instead about a blog with articles and comments:
/blog/article/42 -- representing an article
/blog/article/42/comments -- representing a collection to all comments for this article
/blog/comment/44571 -- representing a single comment
Depending on what you want, a couple of examples for timelines could be resources like:
/user/bob/timeline/home
/user/bob/timeline?type=home
/timeline/home?user=bob
As I mentioned earlier, it's best to avoid using multiple variables in a resource. I would probably pick option 3. The reasons being, besides the complexity of having too many variables, is that such a resource probably isn't worth caching (client-side) and no CUD actions may be done on it. Since it's most likely an aggregate resource for different entities.
A couple of closing words:
Design resources first and only then come up with a matching URL
Don't design resources 1:1 to (business-)models
Don't over think the situation from the start. Implement something and tinker with it to see possible problems in the future. Once you're happy, put it in production.
Suggestions for further reading:
HAL - http://stateless.co/hal_specification.html
Hypermedia - http://en.wikipedia.org/wiki/Hypermedia
RMM - http://martinfowler.com/articles/richardsonMaturityModel.html
Roy Fielding's blog - http://roy.gbiv.com/untangled/tag/rest
I'm building my first REST API (at least trying) for a personal project.
In this project there are resources called players which hold can be in a team. According to REST API design rulebook a resource should be made either to be a document or a store and one should keeps these roles as segregated as possible.
Yet I would like to append some metadata to the team resource, eg the date the team was founded. Is it okay then for GET /teams/atlanta to return this metadata (making it a document) alongside the list of players in the team (making it a store).
Is this a good idea? If so why? If not why not and how to solve this better?
I know there are no rules to developing a REST API, but there are good practices and I would like to adhere to those. Please also not that this is really my first REST API so pardon my ignorance if there is any.
I would recommend having GET /teams/atlanta return just the information about the team, such as the founding date that you mention, and then having GET /teams/atlanta/players return the list of players for that team. These distinctions become more important when you are presenting an API that uses HTTP methods other than GET.
For example, if you wanted to add a player to a team - this would be a lot easier if you could just POST a player object to /teams/atlanta/players than if you had to PUT the whole team object to /teams/atlanta every time you wanted to add one individual player.
If your API only allows retrieval of data, and if it is for a specific client application, there is an argument for combining all the team data into one object to save the client having to make additional requests for the data, but bear in mind that it is less flexible.
Your application may want to display a list of teams by calling GET /teams but you probably wouldn't want all of the player information included in each object in the list as this is quite a lot of data, but if GET /teams/atlanta returns player information then it would be inconsistent not to include it in the list version too.
I would personally favour splitting up the resources as I've suggested, and live with the fact the client may need to make an extra request or two.