interacting with RESTful API through a webpage?

I'm working on a web service and I'm trying to decide whether to make it RESTful or not. I've found lost of information on what REST is, but not a lot on why it's useful.

In particular I'm confused as it seems using RESTful methods makes it very difficult to interact with the service through a client webpage, since you have to use AJAX to submit anything other than the GET/POST queries, and if your service lives on a different server, then it's nigh impossible because of the same origin policy.

Can anyone fill me on on how this is usually done and what benefits REST gives you over something like a si开发者_JAVA技巧mple RPC API?

Modern browsers (HTML5 compliant) support all the appropriate HTTP verbs (GET, PUT, POST, DELETE). For dealing with the same origin policy issue, you can always expose an endpoint on your server to tunnel through to the foreign server.

The benefits gained from REST come (IMO) from the representation of your data model as resources, and not as services. In particular, representation of data model elements can leverage the HTTP caching mechanisms. As well, using a representational model can force a design-time evaluation of your data model that (in my experience) proves to be very useful.

1) Why REST:

Just think of the MVC pattern.

Model-View separation makes especially sense if you have multiple views of the same content.

Now think of REST as a machine-friendly view via an application specific protocol which is easy to implement. Making your application also useful to other developers who want to integrate your application as a web service into their own apps.

REST is an application integration technology.

REST is a good choice if you want to offer a machine and developer friendly web service API to your application.

2) REST vs RPC REST should be per definition implemented in a stateless manner. RPC calls are remote method calls on objects or session variables, which makes RPC APIs stateful and in many situation more expensive.

3) Different REST styles The problem with REST is it's not always easy to map all operations of an object on the common HTTP methods GET, POST, PUT, DELETE, OPTIONS.

Obviously CRUD can be implemented by assigning the 4 CRUD operations on to the GET, POST, PUT, DELETE methods.

But you can also codify in the HTTP body of the POST method the kind of operation, which is the minimalistic GET,POST style of doing REST.

The problem is not all HTTP clients can send a PUT request.

The solution advocated by the CRUD style services is to emulate a PUT request by annotating a POST request with a special HTTP header: X-HTTP-Method-Override: PUT

But this does not solve it, because some exotic firewalls remove this non-standard HTTP header.

Roy Fielding, who coined the term RESTful API, mentions also that he think it is well possible to design a perfectly RESTful system with just GET and POST.

4) Adding REST to an existing MVC web application requires at least the implementation of an extra RESTful controller which translates the HTTP method verbs PUT, POST, DELETE into operations on the model object identified by the request URI but often also the implementation of a more machine-friendly view (JSON,XML,...).