0

If you are not familiar with these terms:

Additional info:

The question: How is it possible to create a single client with HTML hypermedia type which supports progressive enhancement 2.0? So if the browser has no javascript, it gets a pure HTML page, if the browser is on a mobile device, it displays mobile view, if the browser is on a PC, it displays desktop view, etc... I was thinking about this, and I think there is a contradiction in this: single page javascript applications have their own bootstrap HTML file, and they use AJAX to load the data from the server, while noscript clients load and display the data directly from the server in HTML format. The AJAX data format can be HTML too, and I can use microformats to make it easily processable, but I still don't know how to deal with the AJAX vs. noscript problem... Any idea?

Additional thoughts:

I don't think it is possible to apply progressive enhancement 2.0 on hypermedia API-s. By any error a noscript browser should get the whole form with error messages, the ajax aware browser should get only the 400 bad request status header and a small part of error data, because it validates almost everything with javascript. By mobile view we want to display only the navigation of the current level, with desktop view we want to display a deep menu so we send a series of get requests for every rel=up menupoints until we reached api root... By this scenario I need at least 3 different clients with 3 different solutions: mobile, noscript desktop, ajax desktop, and I don't think there is any way to merge them in a single client.

inf3rno
  • 24,976
  • 11
  • 115
  • 197
  • The API server can return html for the noscript clients when requested with the Accept: text/html header, and a machine-friendly format (XML, JSON, etc) for the AJAX client. I don't see where the problem is. – Pedro Werneck Nov 04 '13 at 10:25
  • That won't be "progressive enhancement 2.0", that's the only problem. – inf3rno Nov 04 '13 at 12:44
  • Why not? You have the lowest common denominator in the machine-friendly format, and adds functionality according to accepted media types and available features. – Pedro Werneck Nov 04 '13 at 12:48
  • By RESTful webservices you use a client instead of communicating directly with the webservice. I don't think the webservice should send a HTML with css and js code, the client application should append these parts to the response. I will think about it... – inf3rno Nov 04 '13 at 16:00
  • Not at all. As a matter of fact, providing code on demand to extend client functionality is one of the main principles of REST. There's nothing wrong with the webservice returning any media type, as long as it's respecting the Accept headers. – Pedro Werneck Nov 04 '13 at 16:06
  • REST client <> browser. You can write a js REST client running in the browser, but they will never be the same. You are not capable to send PUT and DELETE requests with HTML only (maybe emulated, but that's not the same). You'll need a server side REST client if there is no javascript in the browser. – inf3rno Nov 04 '13 at 19:28
  • 1
    Sorry, but that's wrong. In REST, a client is a client, doesn't matter if it's a browser, a script or a headless consumer. When you assume that browsers should be dealt with differently you're creating an unneeded coupling. The only constraint applied to clients is that they should enter the API with no previous knowledge. It's clear now that the contradiction you see is a product of this confusion. – Pedro Werneck Nov 04 '13 at 21:46
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/40534/discussion-between-pedro-werneck-and-inf3rno) – Pedro Werneck Nov 04 '13 at 22:03

1 Answers1

0

Progressive enhancement 2.0 is a client thing, it does not depend on the REST API, so it is possible to merge a js-less server side REST client with a js-aware client side REST client. So it is possible to use progressive enhancement 2.0 with a hypermedia API.

By RESTful webservices, the client should store the current state, not the REST service itself. It is possible to use the browser as a REST client, but it will be very short on state storing capabilites. It can store state in HTTP auth, in ETAG, in accept header, in the queryString part, if I send it back from the REST service in every link. Until it is not possible to use localStorage directly from HTML without javascript, the browser as a REST client will be a very poor solution. I don't recommend to use it.

inf3rno
  • 24,976
  • 11
  • 115
  • 197