Hypermedia api with progressice enhancement 2.0 - how is it possible?

Question

If you are not familiar with these terms:

• progressice enhancement 2.0
• hypermedia API

Additional info:

• Building Hypermedia APIs with HTML
• HTML Hypermedia APIs and Adaptive Web Design

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.

Answer 1

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.