How can I extract information from opensocial based networks like orkut.
Many OpenSocial-based networks offer REST and JSON-RPC based APIs, for which there are a variety of client libraries available.
PHP is probably the most sophisticated and compatible client library (and has the best documentation). You can find out more at this page: http://code.google.com/p/opensocial-php-client/wiki/GettingStarted?tm=6
Related
What should I do if I want to embed a live streaming function in my website? There seems to be no solution via Google.
Unless you intend to use some sort of browser plugin, embedding video on a website typically entails the <video> tag. So, most likely, support for livestreaming would entail a networking method of your choosing when recording the live stream (UDP perhaps?) to your server, which would -- in turn -- transcode the data into a format that can be consumed via the <video> tag on the browser. If you only need to livestream between two browsers (like in video chat), then WebRTC is probably your solution.
With the <video> tag, Media Source Extensions makes it possible for the client/server to highly customize the transport of the media streams. For example, a custom MediaSource could send the media using web sockets if it so chose, for example (instead of as an HTTP stream). Because MediaSource extensions allow for such a wide degree of customization, it's really not possible to give one definitive answer regarding the protocols used to communicate with the browser.
And whereas the browser<->server protocols are easily discoverable (just open the developer tools when visiting one of these sites), the underlying server<->server protocols are not.
may I have some example/typical use case of HATEOAS? I agree it can be a very powerful concept provide great flexibility but I am not sure how to properly get benefit from HATEOAS. would be great if you can share your experience/use case.
A good answer from #dreamer above, but HATEOAS is not present in most REST-based services. It is a constraint on the REST architecture style that allows clients to interact with a service entirely via the hypermedia contained in the resources.
If you look at the Twitter or Facebook REST APIs, you won't find hypermedia. Look at the Facebook friendlist resource. There are no hypertext links in that resource that you can use to transition the state of the resource - to delete, update, etc. Instead, you need to read the out-of-band documentation to understand what you need to do to delete that resource.
One of the claimed advantages of using hypermedia in your APIs is that you can manage change within the resources themselves. For example, what if Facebook wanted to add additional functionality to the frendlist? If it were built with HATEOAS in mind, the resource would be updated to add the hyperlinks provides those additional state transitions.
If this sounds difficult, you're right. But as a developer of client applications, however, once you understand how the hypermedia is presented, you can build applications that will evolve along with the API itself.
So how do you build APIs using HATEOAS? A number of options are out there, but I like the Hypertext Application Language (HAL) the best.
UPDATE: Since you asked for an example, here's a link to a demo using HAL.
Good public HATEOAS use cases are hard to find, because there are a lot of misconceptions around REST, and HATEOAS can be hard to implement. You really need to have a good understanding of its benefits, before you're willing to put yourself through the trouble of getting it to work, and if the clients don't follow it correctly, all work will be in vain.
From my experience, implementing proper REST in a company is a culture change as important as moving to version control systems or agile development. Unless everyone adopts it and understands it, it causes more trouble than it solves.
Having that in mind, I think the best example one will find is the foxycart.com HAL API, on the link below:
https://api-sandbox.foxycart.com/hal-browser/hal_browser.html#/
It's very powerful concept used in RESTful presentation of the application to the client. There are many many projects which are adopting this interface now. A typical use case for this is Web Services APIs using RESTful APIs. A RESTful APIs typically consists of the following elements:
base URI, such as http://example.com/resources/
an Internet media type for the data. This is often JSON but can be any other valid Internet media type (e.g. XML, Atom, microformats, images, etc.)
standard HTTP methods (e.g., GET, PUT, POST, or DELETE)
hypertext links to reference state
hypertext links to reference related resources
The application state can be modified using above HTTP methods for example, to get a particular resource, A client can issue a REST query using curl like:
curl -X GET --url "http://example.com/resource/" -X "Content-Type:application/json"
you could go through the man pages for curl and its usage. More on RESTful interface concepts can be looked upon at wiki
Is there any json-only standard to handle resource discovery (ie. collections of editable entries) ?
I mean some "protocol" to use in a self-describing REST service, eventually with hypermedia discovery (read, links and paging)
What about some Atom Publishing Protocol json equivalent ?
Maybe you can use something like this: http://restdesc.org/
Perhaps you should have a look at Hydra (which works with JSON-LD). If you find it interesting, there's a Hydra W3C Community Group you may wanna join.
Here's the recording of a talk in which I describe both Hydra and JSON-LD: Building Next-Generation Web APIs with JSON-LD and Hydra
Disclaimer: I'm the creator of Hydra and the chair of the Hydra CG. I'm also one of the core designers of JSON-LD and a co-author and editor of its specifications.
Maybe you could take a look at JSON-LD:
http://json-ld.org/
A protocol? The whole point of REST is that you just ask a resource for a representation that happens to contain links to other resources. Pretty much any resource can tell you about other resources that happen to be relevant. There isn't a protocol specifically for discovery precisely because discovery is built into the whole architecture.
Some RESTful services publish service descriptions in a format like WADL, which could allow a client to predict the URIs for the some of the sorts of resources that the service provides. But that's not a substitute for actually getting links from other resources published by the service, as those links are concrete whereas WADL talks about URI templates.
Google uses the XML/RSS/Atom-based Google Data APIs to provide programmatic access to its various services.
Because it is Google doing this, these API are becoming quite popular, as in: there are many client applications supporting it. Google even provides a lot of client libraries themselves.
It should be possible to use the APIs for other (non-Google) data-sources, as well.
Is anyone doing this?
If I had to provide an API to my calendar web site, would it be a good move to use Google's API instead of CalDAV, which is a "proper" standard but probably more difficult to work with?
Or are the Google APIs too Google-specific, not well documented enough, or inappropriate for some other reason?
For calendaring, the CalDAV protocol and ICS file format are well established and portable between applications and services. I wouldn't try to copy exactly what Google's APIs do, because they can be specific. Offering REST based APIs with XML/Atom support is not terrible choice. Probably all depends on what you're trying to do. For calendaring, CalDAV/ICS are probably the best choice.
Does anybody know a wiki engine that can be built on top of a RESTful application?
I have a restful application, that exposes a document resource,
I want the wiki engine to use the REST API to persist the documents, instead of saving them to a DB.
I am also open for suggestions of an open-source wiki engines that can be easily modified to support such functionality.
As Wikis were originally designed to work in a standard browser, and most browsers did not support anything except GET and POST, REST is not a concept used a lot on the wiki world. However, nowadays, some wikis (foswiki - the community fork of TWiki for instance) provide you a REST API to it http://foswiki.org/System/CommandAndCGIScripts#rest ).
But you need the opposite: a wiki with a customizable backend (storage) that could be plugged on top of a REST storage service. As wikis with a pluggable backend, I know only of pmwiki http://www.pmwiki.org/wiki/PmWiki/PmWiki and foswiki (the open fork of TWiki) http://foswiki.org.
Okay, this is a puzzler. Wikis in general are more or less the canonical example of a RESTful approach. The page name names a resource. What do you want that isn't in, eg, Twiki?
While you could try to find a wiki that can use a REST backend, it may be better to write a small wiki yourself. Because even though a your backend has REST interface, that doesn't mean you can put some other application in front of it.
dokuwiki does not use a database. It is a filesystem based wiki. I don't know its internal code structure but you might be able to use it as your base.