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.
Related
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
I am little bit confused about what really a web service is. You say Amazone web services,etc like that, they offer information. So what is the requirement to be a web url to be a web service ? Let's say I am not much familiar with web development, how could you explain it to me ? But I can get it if you point some ways.
And also little about SOAP and REST basically for someone really new
What is a web service
It is many things. In programming, in generally refers to a web page, that can be called from an application (be it another web page, or desktop app), and the caller will pass in data to it, or receive data from it.
In this sense, it's basically like a 'method' or 'function' in a normal programming language; except you're calling it over the internet.
SOAP
A message format. As discussed above, a web service is a basically a 'method' or 'function'. SOAP is the 'instructions' and 'data' to this method. It will outline data types, and possibly a bunch of data as well. It is an XML format.
REST
REST is the means of implementing an interface to your application but, implementing access control, and other such things, specifically with HTTP Response codes. So you will get a 401: Denied (I think that's the right code), if you don't have access. There are other types of response codes that are useful. It also makes use of other HTTP commands like PUT/HEAD/OPTIONS.
The W3C defines a Web Service as (quoting) :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network. It has an interface described
in a machine-processable format
(specifically WSDL). Other systems
interact with the Web service in a
manner prescribed by its description
using SOAP-messages, typically
conveyed using HTTP with an XML
serialization in conjunction with
other Web-related standards.
That definition is maybe a bit too restrictive, considering how that term is used nowadays -- I'd probably go with just the first part of that definition, which is quite generalist :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network.
Wikipedia also has some interesting definitions, like :
In common usage the term refers to
clients and servers that communicate
over the Hypertext Transfer Protocol
(HTTP) protocol used on the Web.
From what I've seen :
A couple of years ago, when we said "web service", we generally meant "SOAP, WSDL, ..."
Now, when we say "web service", we often mean "whatever allows to call something on another server, be it SOAP, REST, ..."
A Web-Service can be considered as a set of methods that enables communication amongst applications irrespective of the application's coding language or framework.
http://acharyashri.com/blog/WebServices.html
Think of Web services as remote APIs (since they are basically just that). You have a method that you want to implement. Let's suppose the method wasn't built by you and resides somewhere else in the world on equipment that you have no control over—how can you go about providing that remote method what it needs in order to get instantiated?
When you find a Web service that you want to include in your application, you must first figure out how to supply the Web service with the parameters it needs in order for it to work. That need also extends a bit further. Even if you know the parameters and types that are required for instantiation, you also need to understand the types that are passed to your application in return. Without these pieces of information, using Web services would prove rather difficult.
Just as there are standard ways to represent data as well as standard ways to move this data over the Internet using Web services, there is a standard way to get a description of the Web service you are interested in consuming. Web Services Description Language (WSDL) is a specification of XML that describes the Web services you are interested in consuming. It's just an interface to describe a web service.
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.
I'm beginning a project right now that will require a pretty extensive web back end. Of the different calling conventions, we have found that the easier and more cost effective approach is to build a standard SOAP web service.
So now, we are in the process of looking at the different web service frameworks in order to determine which will meet the business needs:
Security
Cost
Time
I've only worked with WCF, which I was fairly content with, but I would like to explore all other options before I make a definite decision. In your experience, what do you feel is the best web service framework?
Web Services Interoperability Technology (Java)?
WCF (.NET)?
ActionWebService (Ruby)?
On a side note, we need a framework that can securely be accessed via iPhones, Windows Mobile Devices, and Blackberries.
Thanks in advance for your help.
Chris
WCF can be used to make both SOAP and RESTful Web Services. Interoperability is guaranteed as long as you stick to standards. But the more standards you put on it, less platform can catch up. In that sense REST on Basic Auth over https would be very light weight. Also see WS-I Basic Profile. Java vs .NET would be matter of taste, I think. WCF is not perfect, but it mostly seems to do the job.
One thing to consider about WCF is that it has a very rich extensibility model. Anything it doesn't do out of the box, you can teach it to do, with little or no change to your basic service.
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.