What native apps get wrong over web apps

1. They need to be installed. This in itself is a big drawback.
2. They need to be separately developed for each target platform. Unlike the desktop app days where Windows was almost ubiquitous, with mobile you have to support 2 platforms.
3. They can get outdated if users don't upgrade. We are doomed to repeat the same mistakes we made with desktop apps.
4. Deployment is blocked on a black box not in your control (aka the app store approval process). Kiss continuous deployment goodbye.
5. They have no trustworthy way to indicate to users that secure channels are being used to communicate secure information (unlike the address bar in web apps that clearly shows if the connection is secure and to the right place). If you think about it, there is a beauty to REST/HTTP that makes this possible.
6. Each app needs to reinvent the wheel and ship infra that could have been shared, e.g., local data store, caching, etc.

ReverseHttp

ReverseHttp.net  allows HTTP clients to expose webhooks so that servers don't have to implement long-polling.

Routing in Bombay (WIP)

Default routes

Here are some examples that illustrate the default routes I came up with:

Example Request        handler function
---------------------------------------
GET /                  _home()
GET /foo               _show()
GET /foo?baz=qux       _query()
PUT /bar               _save()
DELETE /bar            _delete()
POST /                 _post()
POST /login            _login()
GET /users/            users_home()
GET /users/1           users_show()
GET /users/1?baz=qux   users_query()
PUT /users/2           users_save()
DELETE /users/2        users_delete()
POST /users/           users_post()
POST /users/poke       users_poke()

I chose *_save because it captures both the CREATE and UPDATE semantics of PUT. The other option was *_write() requiring me to use *_read instead of *_show for symmetry but that didn't feel right.

*_query was chosen over *_search and *_filter because its asking semantics is generic enough to be used in many different situation than the locating and removing semantics of the alternatives.

Catchalls

If none of the above handler functions are found, mapper.lib will fall back on the catchall handler functions.

Request        fall-back-1        fall-back-2   
---------------------------------------------
* /users/1     users_catchall()   _catchall()
* /foo         _catchall()

Update July 27, 2009: Renamed Swx to Bombay

The Web Site IS the API

Web APIs Are Just Web Sites:

A short presentation on how you might like to build a simple “Web API”.

I've said this before and the reason it's important for web application developers to understand this is that it changes the way they look at and design web applications. The difference between a Web Service and a Web Application is only in the representation.

The irony of the Web

An interesting comment by Don Park:

Isn't it ironic that much of the Web 2.0 businesses depend on the GET method being non-idempotent? Otherwise, PPC won't generate any revenue.

:)

Making Web Standards Work

More W3C Controversy

We should work on, and implement, the standards that we think are appropriate for Web browsers, and ignore the rest. We should spend our time improving what Web developers and users want, not waste our time improving what is less important or criticizing what isn't going to work in the first place.

+1

Lets talk about REST

Its great to see all this talk about REST. Now if only they could figure out the difference between a resource and its representations (the R in REST) and pry the XML off HTTP and discover media types.

*sigh*

Browser URL Size Limits

Via Rules for Bookmarklets:

Browser	Max chars
Netscape	> 2000
Firefox	> 2000
Opera	> 2000
IE 4	2084
IE 5	2084
IE 6	508
IE 6 SP 2	488
IE 7 beta 2	2084

The evolution of Web Design

• web2.0 logos!


• The Logos of Web 2.0 - A breakdown of the fonts used in some of the above logos.


• The Elements of Typographic Style Applied to the Web - a practical guide to web typography

Yahoo unREST

Saying that they use REST is a misnomer. What they actually use is Browserland HTTP.

Case in point:

By default, Yahoo! Web Services return output in XML format. Some, but not all, of the Yahoo! Web Services can also return Serialized PHP. To get output in Serialized PHP format, use the output=php parameter in the request:

http://api.search.yahoo.com/ ImageSearchService/V1/ imageSearch?appid=YahooDemo &query=Madonna&results=1 &output=php

The RESTful way to do this is with an Accept Request header field.

I did point this out to Rasmus during a Web Services BOF at FOSS.in to which he said that it was easier to call it REST than call it HTTP. I don't buy this. A web developer will be much more familiar with the word HTTP (the thingy you see in the address bar of your browser and in the URI I've quoted above from Yahoo!'s own documentation) than with the word REST (an architectural style for distributed hypermedia systems described in a dissertation by Roy T. Fielding).

Now that that's out of my system, I really like what they are doing with PHP, especially this. I'm using Serialized PHP for representations as well in a web application I'm working on using Inertia with the following media type: application/x-serialized-php.

Browserland HTTP

All this talk about Lo-REST and Hi-REST is so misleading.

There arent two types or levels of REST. There are just Components that support HTTP to various degrees and that is where the problem lies.

For the most part we are trapped in Browserland HTTP:

• Availability of only a subset of the HTTP methods (GET and POST).


• Visibility/Awareness of a subset of the REST Data Elements (resource identifier and representation).


• Cookies!


• Limited or no control of conneg on the client side.


• Broken HTTP Authentication Interface.


• No true client-side state.

The people making the argument that Browserland HTTP is "what’s been proven on the web" and REST is just theory, "speculative", "unproved in practice, and unlikely to be a game-changer" haven't been paying attention.

State of REST

When you get REST and then go back to the drawing board to design your web application/service you realize that we've cornered ourselves in Browserland HTTP and that is the really tragedy of REST: The only protocol that follows the REST architectural style is crippled by its current infrastructure.

Web Service = Web Application

If you get REST, you will get this.

The difference is only in the representation.