Does anyone know how to detect deleted posts in using the Disqus API?
I'm syncrhonizing posts from Disqus using the forums.listPosts method of the API.
The listPosts method does not update the date of a deleted post, so when retrieving posts incrementaly using the since parameter, deleted posts are never retrieved again, thus I cannot delete them (They have an isDeleted attribute).
Any idea, besides brute force, on how to obtain deleted post when they're deleted?
Thanks!
There is no way to sort data by the date it was modified, so there's no direct way to get comments that have been most recently deleted.
About the only option is to occasionally page through all the deleted comments on the site (by only using the "include=deleted" parameter) and update any comments that have changed states the last time they were added to your database.
Related
Let's say an API has the method DELETE for the endpoint /authors/:id, which also deletes all posts by said author.
I understand that, when an author is deleted from the database, all GET requests to /authors/:id/posts should respond with 410 GONE, indicating that said resource is no longer available.
How should the API understand that the resource used to exist but no longer does? After all, the query SELECT * FROM posts WHERE author_id = id; is empty.
The only "solution" I thought of was to not delete the posts, but check the existence of the author in the database and act accordingly.
In most business applications, you don't really want to delete records during the normal flow of operation, especially if you then have to cascade those deletes.
For instance, in a finance application, when a customer stops doing business with you, you don't want to delete that customer record and all the sales in the past - you want to set a flag saying "this customer is no longer active".
That's often referred to as a soft delete.
Your REST API can interpret the deleted status to issue the correct status code (GONE, rather than NOT FOUND)
Right, this is really working on my nerves, but Instagram has to do something about their bloody documentation.
I am already trying for a week to live update my website with new instagram posts without refreshing the page. Twitter was fairly easy, but instagram is just one big mess. Basically I use the realtime Instagram API, the callback and all that stuff is working fine, but thanks to Instagram it does not return me an ID from the post that is new, the callback only returns some basic stuff:
[{"changed_aspect": "media", "object": "tag", "object_id": "nofilter", "time": 1391091743, "subscription_id": xxxxx, "data": {}}]
with this data you are nothing, except for the Tag, but I knew the tag before this callback too so doesn't matter. It actually only tells me that there is a new post. I have tried doing the same request as when the page loads, when this callback occurs, and get the posts that are newer than those already on the page. Unfortunately I have not succeeded in this yet. I have picked the ID from the last posted instagram post, and checked if it is in the callback request, and it's not.
What am I doing wrong?
I'd appreciate some help, thanks!
Edit:
I'd like to note that this is not only a problem with the realtime api, but also with the normal API. I just don't know how to compare data so I don't get duplicates in my database(normal api), or on my website (realtime). I can't find any tutorial or documentation (Yes, I might be blind), that explains to me how to compare data. I can only find the min_id and max_id, but no explanation what these id's contains. I checked these id's with id's from results, and they do not match. It's not an ID from a media item.
I also checked the next_url, and in my logic thinking, this should be a URL to the next page (like Twitter).
Am I looking at this all wrong?
Ok strike my old answer, I changed the way I do this. Here's how I'll do it now.
I still wait for 10 hits on my Real-time subscription, when I reach 10 I send off a new thread (if one is not already running).
The sync thread queries my DB for a value, I need the last min_tag_id I used. Then I query:
https://api.instagram.com/v1/tags/*/media/recent?access_token=*&min_tag_id=*
Try it out here: https://api.instagram.com/v1/tags/montreal/media/recent?access_token=*
You'll get 20 results, and a min_tag_id value. Append that to your url, you'll see you get no results. Wait a couple of seconds and refresh. Eventually you'll get some media, and a new min_tag_id.
(You can ignore the "next_url" value they give you, you won't be using that).
Basically you only need to store that min_tag_id and query until you have no more results, that means you're done then.
When you get a subscription push, you need to query that endpoint (tag / recent).
I normally start an synchronous thread to perform this so I can answer in under 2 seconds to Instagram.
Then you parse that endpoint and look for a "next url" value.
Keep querying that end point, parsing the media and going to the next url until you find your stop condition.
For me I try to match 10 consecutive records in my DB. Basically from the tag, I store media when then meet my business rules.
The Instagram documentation is accurate and actually well written.
The realtime API is working correctly. As stated in the documentation:
The changed data is not included in the payload, so it is up to you
how you'd like to fetch the new data. For example, you may decide only
to fetch new data for specific users, or after a certain number of
photos have been posted.
http://instagram.com/developer/realtime/
You only receive a notification that an update has happened to your subscribed object. It is up to you to call the API to find out what that data is.
You can call the /tags/[tag-name]/media/recent with an access token that you have previously stored on your own server or DB. Then, you should be able to compare the data returned from that endpoint with any data you have retrieved prior, and just pull the objects that you do not yet have.
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 working on a blog-type website in ASP .net MVC3. I am trying to figure out how I will deal with post upvotes/downvotes(I will have to know what users have already voted where to prevent spam voting). Comments on a blog post is another issue.
My thoughts so far(I am sure they are pretty far off the mark):
Votes:
Store a list of UserIDs in a voted field of my Blog table.
For each user in my Users table, store a list of all PostIDs they have voted on.
Comments:
Make a separate Comments table and in that table have a field referencing the parent blog post.
Store a list of CommentIDs in a Comment field in my Blogs table.
I know there are several other ways to go about this but I am trying to set this up so that I won't have to rewrite the whole thing should I get an influx of users.
You might wanna consider creating a Votes table like
User|Post|Type?
john|43 |Up
mary|43 |Down
making User + Post a composite primary key, and thus indexing by both... Then you can easily check if a user has already voted for a post or not... You can also create additional indexes by user or post if needed...
I'd also be a good idea then to have the "Current Ups and Current Downs" in the blogs table, so you don't have to count them each time...
Let's say I have model of posts that belongs to a user. A user has many posts.
Is there a fast and simple way to fetch the latest posts created, but maximum one per user? So even if user A posted the 5 latest post, only the latest is returned, followed by user B's post.
Possible without adding manual logic?
Post.select('DISTINCT posts.*').group(:user_id).order('created_at desc')
The group method will only return one record per group.
Post.group(:user_id)
Update
You can't control which one you get from each group this way but it appears to use the latest one created in the database.