5 ms·

The real shift is thinking about the user interface as just another service, and one best provided by a static web application that talks to your API server and

by mbleigh 13y ago

The real shift is thinking about the user interface as just another service, and one best provided by a static web application that talks to your API server and other services via CORS. As long as you completely split the front-end and back-end, you're able to start with a simple single API and break it into services once you recognize pieces of your application that would work better independently. This also makes it stupid simple to implement new interfaces e.g. mobile apps.

benjamincburns 13y ago
Why CORS?
lstamour 13y ago
I don't think that long-term I'd want any client-code speaking directly to the backend over a generic API. It's far more optimized to migrate to code that sends fewer requests with as little traffic as possible over the wire, and often that means knowing state both on the server and client, which isn't all that RESTful. http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/ http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me... The point is the different design goals: Yes, you can send page after page of HTML, refreshing content that hasn't changed. But we moved to AJAX because that was inefficient. Better to have the browser ask for just the data it needed. Well, efficiency will then lead to either better protocols to bundle up multiple requests or the simpler approach of bundling up data into one request designed for that particular user's session. Hard to put RESTful, meaningful unique IDs on that one. Of course, the risk you run is one I've frequently encountered in Google Music, for instance. The state graph is messed up somehow and duplicate data or corrupt data starts appearing in the JSON stream to the browser and in the UI. Not much you can do except refresh, logout, or wait for a code update to clear such caches, unfortunately. That can be the downside to "smarter" clients and why even today we have cache clearing and a "force-reload" action. This is also why automated backend services should use REST for simplicity, and why UIs need to be built to consider network traffic, re-sending failed requests, checking for invalid data, etc.
- e12e 13y ago
 The sensible way to combine classical REST and AJAX (which I think original AJAX did open for, with it being Asynchronous JavaScript and XML) is to allow requesting partial documents. So if you have: <xml><d>I am initial document, I have only one thing to say, and that is hello!</d></xml> At, /document.xml You should be able to get a partial: I am p2 from something like /document.xml?2 /doucument.xml/2 or something. Then all that could be cached, and you only send new sections. But yes, the client does need to keep some state, because HTML doesn't support transclusion[1] of the "most important" html elements: paragraphs, divs etc. So you can transclude an image, or (badly imnho) an entire document through an iframe -- or javascript (henche modern ajax, which is basically asynchronous javascript and javascript or json which is basically javascript). There's no real contrast between REST and AJAX as an architecture, as such. What's maybe missing is server-to-client PATCH or something (eg: client says I've got d1.html as of <some-date>, give me a diff). Wouldn't that have solved almost all our problems? [edit: I hereby reserve the http method "DIFF" as a reverse "PATCH", as for some strange reason no-one seems to have defined this before (as far as I can google, anyway). Semantics to be hammered out, but in general a client does a "DIFF /<uri>" along with a cache header/timestamp/sha512-hash, and gets back either an unchanged header, or a reply with a patch to be merged with the document/uri in question in order to get an up-to-date copy. In other words, a DIFF is to GET as PATCH is to PUT ] [1] https://en.wikipedia.org/wiki/Transclusion https://en.wikipedia.org/wiki/Transclusion [2] https://tools.ietf.org/html/rfc5789 https://tools.ietf.org/html/rfc5789

by mbleigh 13y ago

benjamincburns 13y ago

Why CORS?

lstamour 13y ago

I don't think that long-term I'd want any client-code speaking directly to the backend over a generic API. It's far more optimized to migrate to code that sends fewer requests with as little traffic as possible over the wire, and often that means knowing state both on the server and client, which isn't all that RESTful. http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/ http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me... The point is the different design goals: Yes, you can send page after page of HTML, refreshing content that hasn't changed. But we moved to AJAX because that was inefficient. Better to have the browser ask for just the data it needed. Well, efficiency will then lead to either better protocols to bundle up multiple requests or the simpler approach of bundling up data into one request designed for that particular user's session. Hard to put RESTful, meaningful unique IDs on that one. Of course, the risk you run is one I've frequently encountered in Google Music, for instance. The state graph is messed up somehow and duplicate data or corrupt data starts appearing in the JSON stream to the browser and in the UI. Not much you can do except refresh, logout, or wait for a code update to clear such caches, unfortunately. That can be the downside to "smarter" clients and why even today we have cache clearing and a "force-reload" action. This is also why automated backend services should use REST for simplicity, and why UIs need to be built to consider network traffic, re-sending failed requests, checking for invalid data, etc.

e12e 13y ago
The sensible way to combine classical REST and AJAX (which I think original AJAX did open for, with it being Asynchronous JavaScript and XML) is to allow requesting partial documents. So if you have: <xml><d>I am initial document, I have only one thing to say, and that is hello!</d></xml> At, /document.xml You should be able to get a partial: I am p2 from something like /document.xml?2 /doucument.xml/2 or something. Then all that could be cached, and you only send new sections. But yes, the client does need to keep some state, because HTML doesn't support transclusion[1] of the "most important" html elements: paragraphs, divs etc. So you can transclude an image, or (badly imnho) an entire document through an iframe -- or javascript (henche modern ajax, which is basically asynchronous javascript and javascript or json which is basically javascript). There's no real contrast between REST and AJAX as an architecture, as such. What's maybe missing is server-to-client PATCH or something (eg: client says I've got d1.html as of <some-date>, give me a diff). Wouldn't that have solved almost all our problems? [edit: I hereby reserve the http method "DIFF" as a reverse "PATCH", as for some strange reason no-one seems to have defined this before (as far as I can google, anyway). Semantics to be hammered out, but in general a client does a "DIFF /<uri>" along with a cache header/timestamp/sha512-hash, and gets back either an unchanged header, or a reply with a patch to be merged with the document/uri in question in order to get an up-to-date copy. In other words, a DIFF is to GET as PATCH is to PUT ] [1] https://en.wikipedia.org/wiki/Transclusion https://en.wikipedia.org/wiki/Transclusion [2] https://tools.ietf.org/html/rfc5789 https://tools.ietf.org/html/rfc5789