Web resources are an integral part of web applications. So what exactly is a web resource? A web resource, generally speaking, is anything returned by an HTTP request. For example, HTML pages are the quintessential web resource. But there are other resource types too — images, CSS style sheets, etc. The browser depends on these resources to properly render the page for the user. So in this sense, what the user sees is actually a decoupled collection of smaller resources.
A few resources are more prevalent than others — HTML, CSS, Javascript. But the fact of the matter is that anything can be a resource — data a remote agent solicits or modifies. We're not limited to what we can serve — can make available to clients. There is no predefined set of resource types.
With the ever growing complexity of applications, the limitless dependencies required to make the thing work — introducing new composite resource types is a foremost advancement toward a better web. Themes are like web pages — a composite type of resource — one that'll be ever more germane to web applications over the next couple years.
Why resources?
So why do we call the things we retrieve with HTTP requests resources? Why not call them web objects or files? The term resource has more to do with the client software than the actual resource itself. The term resource reflects the fact that what the client is fetching is something it needs to function correctly. A dependency of sorts. For example, your television makes use of a digital content stream resource.
The term resource is especially useful when we're describing stuff that has to do with the web. Things that live on the web. The web is called the web because it's interconnected. The the nodes in this graph are the resources.
When we're talking about a particular site, we're more inclined to refer to resources by their type — the page, the image, the flash, the video. But when we're talking on a pure HTTP web-as-hypermedia level, we're better with the ambiguity resources suggest. If some application has an API that lists resources, and an API that retrieves a specific resource, we can design the client around those concepts. Resources are an architectural design idiom while specific resource types describe specific resource attributes.
Themes are abstract
Up until now, we've only touched upon the most general ideas of what makes a resource on the web. Put simply, it's any web-accessible data — you can retrieve it by issuing a GET request. But the client must know about the resource's URI — where is it? Where does the client get such information? From other resources that know about it — this is the interconnectedness that makes the web so powerful.
Now that we have this resource, how does the client know what to do with it? The web browsers people use to surf the web on a daily basis know how to interpret dozens of resource types. In HTTP terms, the resource type is the content type, usually specified in the response headers. If the client knows what the resource contains — it's structure — it can make use of it.
Imagine getting a CSV row with twenty columns in it. Suppose you've hadn't received any schema for this data. You might be able to make sense of some things in the data be deriving their meaning, but you're essentially playing a guessing game. Without a standard (schema), making use of web resources is a lost cause. Web standards dictate a common set of rules so that browsers know how to display information. This is how the browser knows that a CSS web resource is used to alter the appearance of another — the HTML page.
The HTML page and the CSS stylesheet are so commonplace that we hardly think of them as abstract anymore — but they are. They're a simplified set of instructions — more abstract than saying "this group of pixels should be positioned here and should be coloured blue". Humans know how to make sense of higher-level instructions that hide the low-level details.
But even with high-level languages like those of HTML and CSS — languages that hide the messy stuff — we're still able to build applications that are incredibly difficult to comprehend let alone maintain. Web sites and web applications are getting bigger and bigger — there is a cost to that volume. Complexity means longer development time and or more development resources.
Themes are the next level up on the abstraction ladder. A theme is simply the appearance of the site — like how desktop themes let users change the appearance of their local environment. Themes are more abstract than CSS styles because of the standards imposed on them — the same style rules are found in each theme — only the properties change.
Nothing new, just improved
You might be wondering what exactly sets themes apart from any other typical web resource we're used to. Like CSS style sheets. That is what themes are after all — a collection of styles and images. Both of these things we're used to seeing in every web page we visit.
But unlike your typical CSS that we're used to, themes carry a standardized interface HTML pages can utilize. The jQuery UI project really pioneered themes — the new resource type that we've come to expect. This is how we're able to achieve a consistent look and feel across all our applications. The standard theme interface allows this because the applications that use them must adhere to the theme styles.
Themes simply tie together older, more familiar resources that we're used to. They're more abstract, enabling us to build better user interfaces for the web. So are they justified in being referred to as a new resource type? I think so.
No comments :
Post a Comment