Is there a way to get the meta-data of statuses created through the new status update form that is being roll-out to every one since last week (the one where you can attach a location and a place to your post) ?
Right now the only info that gets through the APIs is the status message... which often does not make sense without the shared location :(
There isn't currently a way to access this metadata (location info attached to a post added via the www.facebook.com interface) but where a user checks in from the mobile site or iphone app, this is treated the way it always was on the /checkins connection.
I'm not sure if there are plans to add this metadata to the API, but if it's added it'll either be announced on the roadmap at https://developers.facebook.com/roadmap/ or on the blog at https://developers.facebook.com/blog/
I wonder, I wonder.
It could be that FB is rethinking their API strategy considering location data and privacy issues it might cause. Something that Google and others are facing currently. Otherwise it should be very easy addition to their existing API's.
Related
I'm working in creating a FORM (kind of survey) to get user input, any user who visited the website can provide me information. This would means, the API is actually public accessible to anyone without any token or session (basically nothing)
I want to prevent people from getting my endpoint and create thousand/millions of requests (SPAM) to flood my service and database. I've tried to look over Stackoverflow and some post in medium, it's interesting that I don't find much about this.
Some said:
bundle my website as an hybrid app, supply accessToken to only "trusted device" for firing my api (but this is a pure webapp)
creating custom header and identify the header from my web server (hmm..?)
use CAPTCHA (this will only stop people spamming via the GUI, but spamming via script still possible)
Is this simply no better way to secure, since it's public?
Any thoughts to share?
have you read about Request Queue?
it might help you solve the issue
source 1
source 2
Background:
I have a single page application that pulls data from a REST API. The API is designed such that the only URL necessary is the API root, ie https://example.com/api which provides URLs for other resources so that the client doesn't need to have any knowledge of how they are constructed.
API Design
The API has three main classes of data:
Module: Top level container
Category: A sub-container in a specific module
Resource: An item in a category
SPA Design
The app consuming the API has views for listing modules, viewing a particular module's details, and viewing a particular resource. The way the app works is it keeps all loaded data in a store. This store is persistent until the page is closed/refreshed.
The Problem:
My question is, if the user has navigated to a resource's detail view (example.com/resources/1/) and then they refresh the page, how do I load that particular resource without knowing its URL for the API?
Potential Solutions:
Hardcode URLs
Hardcoding the URLs would be fairly straightforward since I control both the API and the client, but I would really prefer to stick to a self describing API where the client doesn't need to know about the URLs.
Recursive Fetch
I could fetch the data recursively. For example, if the user requests a Resource with a particular ID, I could perform the following steps.
Fetch all the modules.
For each module, fetch its categories
Find the category that contains the requested resource and fetch the requested resource's details.
My concern with this is that I would be making a lot of unnecessary requests. If we have 100 modules but the user is only ever going to view 1 of them, we still make 100 requests to get the categories in each module.
Descriptive URLs
If I nested URLs like example.com/modules/123/categories/456/resources/789/, then I could do 3 simple lookups since I could avoid searching through the received data. The issue with this approach is that the URLs quickly become unwieldy, especially if I also wanted to include a slug for each resource. However, since this approach allows me to avoid hardcoding URLs and avoid making unnecessary network requests, it is currently my preferred option.
Notes:
I control both the client application and the API, so I can make changes in either place.
I am open to redesigning the API if necessary
Any ideas for how to address this issue would by greatly appreciated.
Expanding on my comment in an answer.
I think this is a very common problem and one I've struggled with myself. I don't think Nicholas Shanks's answer truly solves this.
This section in particular I take some issues with:
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The implication I take from this, is that urls on your application are only valid for the life-time of the history file or disk cache, and cannot be shared with other users.
If that is good enough for your use-case, then this is probably the simplest, but I feel that there's a lot of cases where this is not true. The most obvious one indeed being the ability to share urls from the frontend-application.
To solve this, I would sum the issue up as:
You need to be able to statelessly map a url from a frontend to an API
The simplest, but incorrect way might simply be to map a API url such as:
http://api.example.org/resources/1
Directly to url such as:
http://frontend.example.org/resources/1
The issue I have with this, is that there's an implication that /resource/1 is taken from the frontend url and just added on to the api url. This is not something we're supposed to do, because it means we can't really evolve this api. If the server decides to link to a different server for example, the urls break.
Another option is that you generate uris such as:
http://frontend.example.org/http://api.example.org/resources/1
http://frontend.example.org/?uri=http://api.example.org/resources/1
I personally don't think this is too crazy. It does mean that the frontend needs to be able to load that uri and figure out what 'view' to load for the backend uri.
A third possibility is that you add another api that can:
Generate short strings that the frontend can use as unique ids (http://frontend.example.org/[short-string])
This api would return some document to the frontend that informs what view to load and what the (last known) API uri was.
None of these ideas sound super great to me. I want a better solution to this problem, but these are things I came up with as I was contemplating this.
Super curious if there's better ideas out there!
The current URL that the user is viewing, and the steps it took to get to the current place, are both application state (in the HATEOAS sense).
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The starting point of the API is (well, can be) compiled-in to your client. Commpiled-in URLs are what couple the client to the server, not URLs that the user has visited during use of the client, including the current URL.
Your question, "For example, if the user requests a Resource with a particular ID", indicates that you have not grasped the decoupling that HATEOAS provides.
The user NEVER asks for a resource with such-and-such an ID. The user can click a link to get a query form, and then the server provides a form that generates requests to /collection/{id}. (In HTML, this is only possible for query strings, not path components, but other hypermedia formats don't have this limitation).
When the user submits the form with the ID number in the field, the client can build the request URL from the data supplied by the server+user.
I've been looking all over to find the correct API call to block applications via application ID, however I've yet to find it. I'm actually becoming quite certain that it's not possible (for obvious reasons, Facebook revenue being one of them), however I was wondering if anyone knew of a way, even via URL call ('https://www.facebook.com/apps/block.php?id=' + APPID + '&action=block' no longer works correctly, if it ever did.)
Basically I've been making a ruby script to be deployed to help users block spammy and generally unwanted applications via application ID's, the script is almost complete, however I need a method to be able to actually block the applications! If anyone could give me some help, I'd very much appreciate it.
Refer to https://developers.facebook.com/docs/reference/api/application/#banned
Create/Ban
You can ban a user for an app by issuing an HTTP POST request to
APP_ID/banned?uid=USER_ID1,USER_ID2 with an application access token
(i.e. a token created using the app secret, not an application Page
access token as described above). You can specify the following
parameters.
This is not (and probably/hopefully will not ever) possible via API. There are too many reasons to leave it that way. You don't want applications block each other...
This may sounds like a show-stopper for you, but it's not! Generate report arguing the reason why some applications better be blocked/removed/reported and show it to users instructing 'em how to do this.
I have an application that goes and gets a users messages from their facebook account, but I've hit an error.
The user in question has a thread between him and me in his inbox, however it doesn't show up in his API call to /me/inbox with his specific access_token.
I do have a valid token (it works for all other calls), and I know it should be working fine (I am opening it in my browser directly to debug, and the data just does not exist).
There is no second page to view, no limit or timestamp imposed upon it, just missing data.
For testing, we do have every single API permission offered, so I know it is not a permissions problem.
Does anyone have any idea why this could be happening, and how to fix it?
I was struggling with the same problem. I found that using the `/me/threads' endpoint delivers much more complete data.
Update:
However I found out that this endpoint is not available to non-developers for the time being:
https://developers.facebook.com/docs/reference/api/thread/
Question
Is there a usable facebook entry point to the Data Storage API that facebook lists on their app admin page for developers, or should I consider an alternate mechanism? What alternative mechanisms exist to simply persist my information offsite (away from my server app) without stuffing it into a cookie that's prone to expire?
...
Background
The facebook Data Store Admin tool is made available in a facebook App's Settings as seen here: (continue reading below)
However when I visit the DataStoreAdmin link nothing works (i.e. clicking the buttons to define the data store types and objects does nothing - I have tried different browsers).
The Wiki page for Data Store API hasn't been updated recently and the second last update says the beta Data Store was taken offline.
It seems odd the link would be readily available and highly visible at the top of the App configuration area if indeed it's defunct. I was hoping some kind of key/value pair solution to remove the data calls from my own server.
DataStore API is being deprecated, don't use it! You can see this here. You are advised to store the data yourself on your server.