I recently heard term 'Writable API' which is totally new for me. Can anyone explain what does it mean?
A publicly writable API is an API that allows anyone to attach meta-data to objects in the owner's database without changing the original content.
For example, take this object: http://twitter.com/#!/MarsPhoenix/status/1917793215. It is a tweet from the Pheonix Mars Lander.
The tweet is owned by Twitter. But what if I want to tag it and share those tags with the world?
If Twitter opened a writeble API, I could add my own data to this tweet. Say I add the tags "mars" and "nasa" to this object, they would be stored as devon/tag:mars and devon/tag:nasa in their database. If user Bob added a tag of "phoenix", it would be stored as bob/tag:phoenix in Twitter's database.
Now we can both share our tags with the world without overwriting any of Twitter's or each other's data.
Here is a good blog post explaining the concept:
http://blogs.fluidinfo.com/fluidinfo/2011/02/14/what-is-a-writable-api/
I wrote the article #Devon linked to, so agree with him :-) Though I'd change his "without changing the original content" to also say that the addition to the data also doesn't require the permission of the original app either (APIs are in a way largely about permission - they're designed to let you do things, but also sharply limit what you can do).
As a concrete illustration of #Devon's example of putting metadata onto tweets, here's how you can do it with Fluidinfo: http://blogs.fluidinfo.com/fluidinfo/2009/12/01/putting-metadata-onto-tweets-with-fluiddb/
We've also posted some writable API examples, for Boing Boing and Union Square Ventures. See http://blogs.fluidinfo.com/fluidinfo/2011/01/27/how-we-made-an-api-for-boingboing-in-an-evening/ and http://blogs.fluidinfo.com/fluidinfo/2011/02/15/how-i-made-a-writable-api-for-union-square-ventures-in-an-hour/
We have a couple more nice examples coming out this week at the LAUNCH conference in SF.
Hope that helps!
Terry Jones
A Writable API would be an API that allows you to write data to the target system/platform rather than a Read-Only API.
For example, StackOverflow/StackExchange provides a Read-Only API whereas the Twitter API is Writable.
Related
I see either link them directly or visual attribute them. Example: say my website provides a recommendation directly to a user based on their submitted interest, do I just make sure "powered by Foursquare" shows underneath?
Any help would be appreciated! I'm new to tech development
These policies are generally more vague on purpose. Rule of thumb: If you're showing any data to users that isn't your own, it should be clear to them where it's coming from. This is done so the data provider gets proper attribution but also can protect yourself against content being displayed on in your app/site.
For Foursquare specifically, it seems like you would need to include a "Powered by Foursquare" icon and optionally provide a link to the venue if the user may need more information about the place.
Lets consider the following flow to a RESTfull API:
API root
|
v
user list
|
v
user details
|
v
user messages
Suppose I have a client to consume the API, and I want to retrieve messages from a user with ID 42.
From what I've been studying, my client is not supposed to know how to "build" urls, and it should follow the links given by the API.
How should I do to retrieve messages for the user with ID 42?
The only way I can think is "walk" the whole API from it's root to user messages, which doesn't look very pretty or efficient to me.
Eg:
1 - GET / and get the link to the list of users
2 - GET /user/?id=42 and get the link to details of the user with the ID 42
3 - GET /user/42/ and get the link to user 42 list of messages
4 - GET /user/42/messages/ and finally get the user messages
Did I get something wrong? Is this the right way according to Roy's Fielding paper?
Or is it ok to just assume the messages url is "/user/{id}/messages/" and make the request directly?
Use URL templates in your API root. Let the client consume the API root at runtime. It should look for a URL template named something like "user-messages" with the value of "/user/{userid}/messages/". Then let the client substitute "42" for "{userid}" in the template and do a GET on the resulting URL. You can add as many of these URL templates you want for all of the required, often used, use cases.
The difference between this solution and a "classic" web API is the late binding of URLs: the client reads the API root with its templates at runtime - as opposed to compiling the client with the knowledge of the URL templates.
Take a look at the HAL media type for some information about URL templates: http://stateless.co/hal_specification.html
I wrote this piece here some time ago to explain the benefits of hypermedia: http://soabits.blogspot.dk/2013/12/selling-benefits-of-hypermedia.html
I believe what your real concern is should you go about implementing HATEOAS or not. Now as it's an integral part of REST specifications, it is recommended that each entity should have a link to it's child entity that it encompasses. In your case, API ROOT should show list of users with each "user" having a link (/root/users/{id}) to corresponding user's details. And each User details entity will contain a link to the list of "messages" (/root/users/{id}/messages) which, finally, inturn encompass the link to the actual message detail as well (/root/users/{id}/messages/{messageId}). This concept is extremely useful (and thus a part of the specifications) because the client doesn't need to know the url to where your entity is exposed. For example, if your users were on http://users.abc.com/rest/users/{id} but your messages were on http://messages.abc.com/rest/{userId}/messages/{messageId}, the user entity that encompasses the list of "messages" will already have link embedded to point to the right resource on a different server.
Now that being said, I haven't actually seen many REST implementations out there (I must admit I do not have TOO MUCH of an experience, but enough to give an opinion) where HATEOAS is being used widespread. In most cases the resources are almost always on the same server (environment) and the paths to resources are almost always relative to the root url.Thus, it doesn't make sense for the clients to parse out the embedded links from the object when they can generate one by themselves, especially when the client would like to provide access to a resource directly (View the message directly without getting the user entity provided you already know what the messageId is).
In the end, it all depends on how close do you want your REST implementations to that of specifications and what kind of clients are you going to have. My 2 cents would be: if you have time, implement REST with HATEOAS and feel proud about it :). There are libraries out there that will make this implementation (HATEOAS) somewhat transparent to you REST implementation (I believe spring has one, although not very mature. You can look at it here). If you are like me and don't have much time to go that route, I think you can continue with a normal REST implementation without HATEOAS and your clients will still be OK with it (or so I hope!)
Hope this helps!
I found this article about hacking urls: Avoid hackable URLs.
There is a very interesting discussion about the topic of this question in the comments section.
I'd like to try to create a Yahoo Pipe that will return ALL of the articles, urls, and # of saves on Delicious which are tagged with the category, for instance, 'sushi'.
Is that possible? (I know I can do it with my own tags, or with those in my network. And I know I can simply go to Delicious and push the load more button until I exhaust the list.)
But a json structure or an XML output file would be so much easier to process.
Would anybody have a clue how to get this?
In order to access delicious data in your application, you’ll need to get a Yahoo! API key and configure it to use delicious social bookmarking. You can do this by creating a project for your application. https://developer.apps.yahoo.com/dashboard/createKey.htmlThere are examples at this second link showing something similar to what you are trying to do.
Read more here:
http://developer.yahoo.com/delicious/
Graph API is not returning image("picture" attribute) for objects corresponding to community pages, which used to be returned earlier. For example this https://graph.facebook.com/178790412179919 does not have picture attribute whereas the corresponding page has an image.
Also the FQL query done on the "albums" connection for some objects does not have a "cover_pid" attribute for an album corresponding to type "profile", which again used to work earlier.
Does anybody know if anything has changed in Graph API corresponding to this in last couple of weeks (I am fairly confident it used to work earlier in the expected way). I looked through Facebook API release notes but could not find any changes corresponding to this. Please let me know if this not appropriate post for this forum.
https://developers.facebook.com/docs/reference/api/page/
picture is a connection, not an attribute. So ...
https://graph.facebook.com/178790412179919/picture
And as the docs say: Returns a HTTP 302 with the URL of the user's profile picture.
Kinda goofy? Yes, but it works exactly as the docs say it does. I suspect they implemented it this way so it could easily be used in an <IMG> tag.
UPDATE:
It still works via FQL. In your case:
https://api.facebook.com/method/fql.query?query=SELECT+page_id%2C+pic+FROM+page+WHERE+page_id+%3D+178790412179919&format=json
I can confirm that this PREVIOUSLY worked, but NO LONGER works. Facebook have removed the picture connection from Community Pages.
I suspect the reason is that most of these images are pulled from Wikipedia, and there was a licensing / attribution issue.
Unfortunately, Facebook is no longer a reliable source of images for entities (e.g. bands).
Is it possible to make a Facebook app which edits user's post on his wall automatically (edits EVERY POST that user makes, app has user's permission and everything)
I don't think that's possible, but maybe I'm wrong?
Based on the Graph API docs, I actually think it could work.
Get the extended permission called
"offline_access". See
http://developers.facebook.com/docs/authentication/permissions
Periodically pull from
https://graph.facebook.com/PROFILE_ID/feed
to see if the user has posted new
posts.
If so, for each new post that has appeared:
Pull and store the text of the post.
Manipulate the text as desired.
Delete the original post using
"DELETE". See
http://developers.facebook.com/docs/api#deleting
Publish your modified version of the
post using "POST". See
http://developers.facebook.com/docs/api#publishing
#Jon: You cannot delete a post that your application has not published.
See here: https://developers.facebook.com/docs/reference/api/post/
No, it's not possible for security reasons. Even though you probably have the best of intentions, there are lots of people who unfortunately don't. The few ruin it for all.