Direct or REST which is the best? :-)

[misha]

Hi guys,

My big dilemma is whether should I use:
1. Ext.direct and its PHP provider
2. or Zend framework that generates appropriate REST pages for Ext.

Is the main difference deciding whether I want my server API to be RPC or REST?

Are there any drawbacks in using direct btw?

[dj]

If your backend needs to communicate with other systems that support RESTful services then you should implement a REST interface. Besides that REST interface I would implement an Ext.Direct router that is the central place for all ExtJS communication. The benefit of having this central router is that you can batch several requests so that only one HTTP request is sent to the server. You cannot do that with directly using the REST interface of your backend but if your application makes many small requests (as it probably would if you use a REST architecture) it greatly benefits from batching requests.

If your backend is only used with your ExtJS frontend then don't bother implement a REST interface.

[misha]

Thanx dj,

The thing is that I would like to publish API interface of my backend for others to use too, so REST would be a bit more logical for that.

You gave batching as main reason for using direct. But isn't batching possible with REST approach too?

I can set autoSave to false on my restful store, and call save() by hand, so all changes to the store will be submitted in one call as opposed to multiple calls if autoSave is true, right?

[dj]

The thing is that I would like to publish API interface of my backend for others to use too, so REST would be a bit more logical for that.

Sure, REST is widely used and as such is a better fit for a public API. However, using Ext.Direct as an router between your REST interface and your ExtJS frontend makes sense...

You gave batching as main reason for using direct. But isn't batching possible with REST approach too?

I can set autoSave to false on my restful store, and call save() by hand, so all changes to the store will be submitted in one call as opposed to multiple calls if autoSave is true, right?

... because HTTP request batching is not possible with REST. It's quite a core concept of REST that each resource has a unique URI. If you want to update user 1 and user 2 you have to POST to /my/RESTful/interface/user/1 and /my/RESTful/interface/user/2. That are 2 HTTP requests and you cannot batch them into one. If you did that it wouldn't be REST anymore.

If you call save() on a batchSave:true, restful:true store, it will generate multiple HTTP requests. One for each updated/newly created/deleted record. Calling save() on a Ext.Direct enabled store with batchSave:true only generates one HTTP request regardless of how many updated, new or deleted records are in that store.

[grzegorz.borkowski]

You can do batching with REST, using WebDAV extensions. See for example HTTP status code 207 created for this purpose.

[dj]

You can do batching with REST, using WebDAV extensions. See for example HTTP status code 207 created for this purpose.

Do you have more information about this? HTTP status code 207 is a response code. How would one do a request that should return this response code? As far as I understand [1] and [2] one would need one single URL that the request has to go to and you would also need some sort of a router on the server. AFAIK such a router is not part of a REST interface.



[1] http://www.webdav.org/specs/rfc2518....tatus.response
[2] http://restpatterns.org/HTTP_Status_...-_Multi-Status

[grzegorz.borkowski]

Yes, you need some filter/proxy on the server facade which acts as splitter for incoming requests, and as aggregator for outcoming responses. If it is REST interface or not, it depends how you define REST For details how to use such batching, you should probably look at WebDAV specifications. Also as far as I know Subversion uses WebDAV, so perhaps you can find some examples in SVN documentation.
But I never used this feature personally, so I'm not a competent person to give you much help on this topic.

[Nalfein]

Are there any drawbacks in using direct btw?

You lose simplicity, browser caching and scalability.

The argument with batching request is a red herring in the discussion. REST supports batch requests natively at HTTP level, using persistent connections! All modern browsers support that. All you have to do is to send appropriate headers.

When you make proper use of browser caching you will gain another boost in performance.

I don't know why Ext's creators decided to use a RPC solution. It is a step back.

[mnovakovic]

I guess that we all agree on that any good application should have some kind of API exposed over REST, which is currently widely accepted "standard" (not to say that is ql).

So if i need to use REST for this purpose why should i use Direct and how should i use it because i would then need 2 points of access for clients which can be hard to maintain at some point...

[dj]

You lose simplicity, browser caching and scalability.

Simplicity and browser caching I understand and I (at least with browser caching) agree with. Could you elaborate on why one would loose scalability?

The argument with batching request is a red herring in the discussion. REST supports batch requests natively at HTTP level, using persistent connections! All modern browsers support that. All you have to do is to send appropriate headers.

Persistent connections are a bit ambiguous in this domain so to clarify that we are talking about the same thing: HTTP 1.1 Persistent Connections: keeping the TCP connection open after one HTTP request finished so that further HTTP requests can be made without the overhead of establishing a TCP Connection first. Header involved Connection: keep-alive and Keep-Alive: 123.

You are right modern browser support that and automatically set these header for XHRs. That's great because the TCP connection does not need to be reestablished for every XHR. But sending multiple XHRs as opposed to only one batched XHR is nevertheless slower because: (a) of the added HTTP overhead (Header, HTTP roundtrip) (b) even modern browser only support 2 or 6 parallel TCP connections to one domain. Pipelining the requests through available TCP connections brings another overhead. (c) Content encoding algorithms (i.e. gzip/deflate) can only see and process the individual response. That's not as efficient as gzip'ing the batched response (one dictionary, synergy effects).

I cannot quantify the overhead of (a), (b) and (c) but I did see a significant speed improvement after implementing Ext.Direct's RemotingProvider in one of my apps so I assume that it is significant.