In this paper we take a fresh approach to explaining the core principles of REST, by describing a World Wide Web that fails to meet these tenets. We look at each key element, resource orientation, the uniform interface, media types and hyperlinking, and imagine the consequences of not abiding by the REST architectural style on the end user or tools developer of the Web. We then do a similar analysis in the context of Web services and programmatic consumers, reexamining each REST characteristic, describing common mistakes and suggesting improvements. We have found that in discussions, the analogy of the World Wide Web has been very effective at explaining REST.

In many cases, we treat web browsers as a black box. But as we gain a better understanding of how they work, we not only recognize where to make smart optimizations but also we push them farther.

The links below capture most of the resources that explain the innerworkings of web browsers.

It also seems to me that we have everything to gain by beginning our work on a data format with no particular serialization in mind. We could go from RDA to RDA-as-data and then on to RDA-as-RDF. I see some dangers in skipping the middle step, mainly that we could end up making some decisions that fit RDA into RDF but that are problematic for other serializations.

The syntax of HTML, along with rules for how to parse content using those syntaxes.

Documents are built from elements. These elements form a tree using the DOM. This section defines the features of this DOM, as well as introducing the features common to all elements, and the concepts used in defining elements.

The conformance classes, algorithms, definitions, and the common underpinnings of the HTML specification.

"…if there are two different things that need to be associated (the described resource and the description resource), then why not just link them, allowing clients to simply discover those links, and then act accordingly."

There are many situations where it would be useful to be able to publish multi-dimensional data, such as statistics, on the web in such a way that it can be linked to related data sets and concepts. The Data Cube vocabulary provides a means to do this using the W3C RDF (Resource Description Framework) standard. The model underpinning the Data Cube vocabulary is compatible with the cube model that underlies SDMX (Statistical Data and Metadata eXchange), an ISO standard for exchanging and sharing statistical data and metadata among organizations. The Data Cube vocabulary is a core foundation which supports extension vocabularies to enable publication of other aspects of statistical data flows.

DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. This document defines the schema and provides examples for its use.

By using DCAT to describe datasets in data catalogs, publishers increase discoverability and enable applications easily to consume metadata from multiple catalogs. It further enables decentralized publishing of catalogs and facilitates federated dataset search across sites. Aggregated DCAT metadata can serve as a manifest file to facilitate digital preservation.

"Raw data" vs. APIs.

A set of best practices and simple approach for a read-write Linked Data architecture, based on HTTP access to web resources that describe their state using RDF.

Ian Hickson's post in which he announces (kind of) the formation of the WHATWG and the break from the "out of touch" W3C.

Google's usability study to test the microdata feature of HTML5.

Ian Hickson's original microdata proposal.

This version accompanies the developement of RDFa 1.1 Core. As that document is not final yet, this service, and the underlying code, will change frequently until the development of RDFa 1.1 is finalized. The implementation may actually run ahead of the “official” version and implement the version in the editors’ draft already… Also, the package available for download may be out of sync with the code running this service.

A pattern catalogue for modelling, publishing, and consuming Linked Data.

In order to consolidate and decode some of the information you need to sift through when learning about rich snippets, we've created this visual guide to walk through the basics, fundamental types, implementation, and benefits of utilizing them.   

Although it is necessary for a service to be RESTful in order to build a system that exhibits RESTful characteristics, it is not sufficient.    The client needs to behave RESTfully or the coupling that the server tried to avoid will be re-introduced.

The following levels are my initial attempt to classify clients based on how coupled the client is to the service API. 

ROCA is an attempt to define a set of recommendations — independent of any particular framework, programming language, or tooling — that embodies the principles of what we consider to be good web application architecture. Its purpose is to serve as a reference, one that can be implemented as-is or be compared to other approaches to highlight diverging design decisions.

Microformats, RDFa and microdata all enable consumers to extract data from HTML pages. This data may be embedded within enhanced search engine results, exposed to users through browser extensions, aggregated across websites or used by scripts running within those HTML pages.

This guide aims to help publishers and consumers of HTML data use it well. With several syntaxes and vocabularies to choose from, it provides guidance about how to decide which meets the publisher's or consumer's needs. It discusses when it is necessary to mix syntaxes and vocabularies and how to publish and consume data that uses multiple formats. It describes how to create vocabularies that can be used in multiple syntaxes and general best practices about the publication and consumption of HTML data.

On a number of occasions I have found a diagram like the one below is useful for visualizing an API.  It lets me see how a client will surf the API to get at the information it wants.  This is not any kind of official diagramming methodology.  I just use class diagrams and use the associations to represent links between resources and the classes represent a “kind of resource”.  I use that vague term because one box in this diagram may represent multiple actual resources in our real system.

This should give a rough overview over the usage of the different formats.

Issues with Twitter's #hashbang URLs are "very real": #webinfo

All you have to do is view source on any nytimes.com article published on or after January, 23 2012. In the HTML you will see new attributes like ‘itemtype’, ‘itemprop’ and ‘itemid’. If you paste an article URL into the Google Rich Snippets tool, you can see a parse of the structured data now embedded into every nytimes.com article,

Like the DTD-based W3C markup validation service, this service checks the markup validity of Web documents, but instead uses the backend from the Validator.nu engine. The default setting of the validator validates HTML5 with RDFa 1.1. Lite and with microdata, the two simpler syntaxes to add structured data to HTML.

Let me show you which steps have to be taken to generate a high-quality text mining application, ready to be used to annotate and to categorize any kind of text or documents covering nearly any domain. With our approach of thesaurus based text mining your documents can also be linked to the world of linked (open) data; enrich your documents with data from the LOD cloud!

This article is an introduction to Microdata and Schema.org. The first section describes what HTML5, Microdata and Schema.org are, and the problems they have been designed to solve. With this foundation in place section 2 provides a practical tutorial of how to use Microdata and Schema.org using a real life example from the cultural heritage sector. Along the way some tools for implementers will also be introduced. Issues with applying these technologies to cultural heritage materials will crop up along with opportunities to improve the situation.

Web Data Commons will extract all Microformat, Microdata and RDFa data that is contained in the Common Crawl corpus and will provide the extracted data for free download in the form of RDF-quads as well as CSV-tables for common entity types (e.g. product, organization, location, ...).

A user agent is any software that retrieves and presents Web content for end users or is implemented using Web technologies. User agents include Web browsers, media players, and plug-ins that help in retrieving, rendering and interacting with Web content. The family of user agents also includes operating system shells, consumer electronics with Web-widgets, and stand-alone applications or embedded applications whose user interface is implemented as a combination of Web technologies.

Nice diagrams of various internet protocol headers.

Vannevar Bush's famous paper "As We May Think" (1945) described an imaginary information retrieval machine, the Memex. The Memex is usually viewed, unhistorically, in relation to subsequent developments using digital computers. This paper attempts to reconstruct the little-known background of information retrieval in and before 1939 when "As We May Think" was originally written. The Memex was based on Bush's work during 1938-1940 developing an improved photoelectric microfilm selector, an electronic retrieval technology pioneered by Emanuel Goldberg of Zeiss Ikon, Dresden, in the 1920s. Visionary statements by Paul Otlet (1934) and Walter Schuermeyer (1935) and the development of electronic document retrieval technology before Bush are examined.

Kevin Kelly's notes on _The Man Who Wanted to Classify the World_, a French documentary on Paul Otlet.

NYT article on Paul Otlet, with an excellent graphic explaining the Mundaneum system, and a video excerpt from the documentary on him.

Michael Buckland's notes on Paul Otlet, with links to other Otlet resources.

"Paul Otlet (portrait) was born in Brussels, Belgium, in 1868. His monumental book Traité de documentation. (Brussels, 1934) was both central and symbolic in the development of information science - then called 'Documentation' - in the first half of this century. In addition, it reminds us of something that has been too widely forgotten: That this field did have a lively existence in the early decades of this century and a sophistication concerning theory and information technology that now commonly surprises people."

Codecademy is the easiest way to learn how to code.

CouchApps are JavaScript and HTML5 applications served directly from CouchDB. If you can fit your application into those constraints, then you get CouchDB's scalability and flexibility "for free" (and deploying your app is as simple as replicating it to the production server).

Source code for the O'Reilly book of the same name.

Optional readings for Robert Wilensky's CS 294-3: Distributed Information Management course at UC Berkeley.

Readings for Robert Wilensky's CS 294-3: Distributed Information Management course at UC Berkeley.

Lecture notes for Robert Wilensky's CS 294-3: Distributed Information Management course at UC Berkeley.

The purpose of this course is to examine ongoing research issues related to digital documents. As suggested by the title, major themes include information representation, information presentation, information linking, and information interoperation. Implicit in these issues are also issue of collaborative use of information, i.e., how networks of information using users can be greater than the same of their parts.

The goal of the course is to lay the foundation for further evolution of networked digital document systems. The ideal student is one with lots of initiative, who enjoys learning together with students from different disciplines, and is excited by the prospect of identifying the important questions to ask, and by the opportunity to shape the directions of an incipient technology.

The course will cover some fundamental technologies, but also examine ongoing (and continually evolving) attempts to bring such technologies into common use. The course will comprise weekly readings, lectures followed by discussion of papers and issues, and occasional guest lectures. Students will work on assignments and a course project, which they will report on in class toward the end of the semester.

Ideally, student projects will advance the state of the art of "network-centric" digital documents.

I'm beginning to see that some parts of the Web we take for granted are not what actually defines it. The Web is not HTML, CSS, and JavaScript. It's not DOM, SVG, WebGL, PNG, or Flash. The Web is really just HTTP over TCP/IP. What gets transported over HTTP does not define the Web.

There is, however, one other characteristic that does define the Web, and that is the humble hyperlink. Links are a feature of HTML, but they are not limited to HTML. Links are the connections that give the Web its name, and links are the biggest thing missing from native platforms.

My definition of the Web then is resources loaded over the Internet using HTTP and then displayed in a hyperlink-capable client.

Microformats, RDFa and microdata all enable consumers to extract data from HTML pages. This data may be embedded within enhanced search engine results, exposed to users through browser extensions, aggregated across websites or used by scripts running within those HTML pages.

This guide aims to help publishers and consumers of HTML data use it well. With several syntaxes and vocabularies to choose from, it provides guidance about how to decide which meets the publisher's or consumer's needs. It discusses when it is necessary to mix syntaxes and vocabularies and how to publish and consume data that uses multiple formats. It describes how to create vocabularies that can be used in multiple syntaxes and general best practices about the publication and consumption of HTML data.

his courses focuses on understanding the Web as an information system, and how to use it for information management for personal and shared information. The Web is an open and constantly evolving system which can make it hard to understand how the different parts of the landscape fit together. This course provides students with an overview of the Web as a whole, and how the individual parts it together. We briefly look at topics such as Web design and Web programming, but this course is not exclusively designed to teach HTML or JavaScript. Instead, we look at the bigger picture and how and when to use these and other technologies. The Web already is and will remain a central part in many information-related activities for a long time to come, and this course provides students with the understanding and skills to better navigate and use the landscape of Web information, Web technologies, Web tools, and common Web patterns.

1 - Find the set of architecture properties of key interest[1]
2 - Formulate an active approach to defining our an architecture that
induces these properties[2]
3 - Then, using the collective knowledge of already existing styles [3]
4 - Develop a style that meets the needs of the identified problem domain

This process is the actual topic of Fielding's dissertation. "REST" is
just his example "step 4" from above.

Despite the Web's great success as a technology and the significant amount of computing infrastructure on which it is built, it remains, as an entity, surprisingly unstudied. here, we look at some of the technical and social challenges that must be overcome to model the Web as a whole, keep it growing, and understand its continuing social impact. A systems approach, in the sense of “systems biology,” is needed if we are to be able to understand and engineer the future Web.

The primary goal of this tutorial to close the gap between the high-level concept of Service-Oriented Architecture (SOA), and the question of how to implement such an architecture once services have been identified. Colloquially, it is often assumed that services in a Web-oriented are implemented as Web services, and these are often exclusively perceived as using the SOAP stack of protocols. Our goal is to describe that Web services can also use other technologies, such as RESTful implementations on top of HTTP. Furthermore, we will explain how a disciplined process can lead from the business level, which is mainly about identifying services on an abstract level, to an IT architecture, and that it is important to not impose architectural constraints (such as defining service in a function-oriented way rather than in a resource-oriented way) too early in the process.

The primary activity of the TAG is to develop Architectural Recommendations. The TAG findings listed below document fundamental principles that should be adhered to by all Web components. The TAG expects to include these findings in the TAG's Architectural Recommendations, to be published according to the requirements of the W3C Recommendation Track process.

The World Wide Web uses relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media. In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web. They are identification of resources, representation of resource state, and the protocols that support the interaction between agents and resources in the space. We relate core design components, constraints, and good practices to the principles and properties they support.

HTML5 is more a movement (or maybe it's more appropriate to call it a brand) than it is a technology. it says more power to the browser and mostly means more power to the browser as a programming platform. given this focus of HTML5, it is surprisingly hard to find a good place where all the APIs under development are listed. this page is an attempt to collect that information in one place.

At a first glance there might appear to be an obvious alignment and overlap between the approaches prescribed by REST and Linked Data. On more detailed inspection divergences in scope and applicability present themselves, and for some aspects, incompatibility. In this paper we investigate these similarities and differences and suggest the coupling is worthy of a third look: in combination as a exible environment in which the developer can focus on domain driven applications.

The term “Linked Data” refers to a set of best practices for publishing and connecting structured data on the Web. These best practices have been adopted by an increasing number of data providers over the last three years, leading to the creation of a global data space containing billions of assertions— the Web of Data. In this article, the authors present the concept and technical principles of Linked Data, and situate these within the broader context of related technological developments. They describe progress to date in publishing Linked Data on the Web, review applications that have been developed to exploit the Web of Data, and map out a research agenda for the Linked Data community as it moves forward.

Presentation from Cesare Pautasso and Erik Wilde.

• There are two distinct relationships between names and things. Reference is different from access. The architecture of the Web determines access, but has no direct influence on reference
• Reference can be established by ostention or by description. Description is inherently ambiguous; ostention can be done only to accessible entities.
• Therefore, references to non-accessible entities - the vast majority of references - must be by description, and hence must be ambiguous.
• Reference to accessible entities still differs from access. Establishing reference by ostention requires naming conventions. Access is one form of ostention.

HTTP URIs, in the web architecture, have been used to denote documents -- "web pages" informally, or "information resources" more formally. However, with the growth of the Semantic Web, which uses URIs to denote anything at all, the urge to use and practice of using HTTP URIs for arbitrary things grew steadily. The W3C Technical Architecture group eventually decided to resolve the architectural problem that if an HTTP response code of 200 (a successful retrieval) was given, that indicated that the URI indeed was for an information resource, but with no such response, or with a different code, no such assumption could be made. This compromise resolved the issue, leaving a consistent architecture.

I believe that this solution enables people to name arbitrary
resources using the "http" namespace without any dependence on
fragment vs non-fragment URIs, while at the same time providing
a mechanism whereby information can be supplied via the 303
redirect without leading to ambiguous interpretation of such
information as being a representation of the resource (rather,
the redirection points to a different resource in the same way
as an external link from one resource to the other).

I didn't have this thought out a few years ago. It has only been in actually building a relatively formal system on top of the web infrastructure that I have had to clarify these concepts my own mind. I am forced to conclude that modeling the HTTP part of the web as a web of abstract documents if the only way to go which is practical and, by the philosophical underpinnings of the WWW, tenable.

history has shown that the HTTP protocol is a very flexible protocol and that not all implementations need to follow the example provided by Fielding in order to meet the needs of users. for example, RPC over HTTP works just fine for many cases; esp. those that do not require system stability on the scale of years/decades.

however, the more important it is for the solution to continue to operate (and evolve) over an extended period of time, the more useful are the additional constraints Fielding identified in his example and the more important it is to optimize for run-time stability over ease/speed of initial implementation.

URLs can be used to identify abstract concepts or other things that do not exist directly on the Web.  This is sensible, but it means that the same URL might be used in conjunction with four different (but related) things: a name, a concept, a Web location or a document instance.  Somehow, we need conventions for denoting these four different uses.  Two approaches are available: different names or different context.  The "different names" approach requires new URI schemes or conventions; the "different context" approach requires syntactic conventions for indicating the intended context.

This document analyzes the definition of "resource" in RFC2396 [1] in an attempt to understand it.  It notes ten questions or points of confusion (labeled QUESTION1 - QUESTION10) that I encountered.
 
WARNING: This analysis is painfully detailed, and somewhat rambling (sorry!), reflecting my thought process as I (honestly) attempted to understand the definition.  It is only recommended to those who believe that the definition is clear, and want to see evidence to the contrary.

To be a full-fledged format on the Web, you need to support links -- something sorely missing in JSON, which many have noticed lately.

In fact, too many; everybody seems to be piling on with their own take on how a link should look in JSON. Rather than adding to the pile (just yet), I thought I'd look around a bit first.

ql.io is a declarative, evented, data-retrieval and aggregation gateway for quickly consuming HTTP APIs. ql.io re-uses concepts and syntax from SQL and JSON to create an imperative style language. Scripts written in this language can make HTTP requests to retrieve data, perform joins between API responses, project responses, or even make requests in a loop.

REST is the architectural style of the Web, and closely related to REST is the concept of a HTTP API. A HTTP API is a programmer-oriented interface to a specific service, and is known by other names such as a RESTful service contract, resource-oriented architecture, or a URI Space.

I say closely related because most HTTP APIs do not comply with the uniform interface constraint in it's strictest sense, which would demand that the interface be "standard" - or in practice: Consistent enough between different services that clients and services can obtain significant network effects. I won't dwell on this!

One thing we know is that these APIs will change, so what can we do at a technical level to deal with these changes as they occur?

There are a number of different ways to deal with media types when designing a RESTful HTTP system.

RequestBin lets you create a URL that will collect requests made to it, then let you inspect them in a human-friendly way. Use RequestBin to see what your HTTP client is sending or to look at webhook requests.

The subjects covered in this document are large and complex, and there is a risk of growing to become unwieldy. The scope of the document is limited, though: to summarize the design considerations important for creating W3C specifications that enable stable standards for the Web, in a way that the Web standards community can discuss issues and altenatives with a common framework, and the evolution of the Web not hindered by interoperability concerns.

One of the important aspects of the Web that is, unlike many other communication applications, there is a broad community of Web developers: designers, programmers, individuals, software engineers, who create instances or strings intended for use in the languages of the Web. Because of the breadth of users as well as large numbers of implementations, the evolution and standadization of the Web has been different from the evolution of most previous communication standards. The history of the evolution of the web is messy: "browser wars", "best viewed by", widespread misunderstanding, slow standards. If we understand better the way in which the Web evolves, we can facilitate the development of useful standards.

Michael Mahemoff discusses how HTML5 can be used to create single page web apps offering advice to create a better user experience, built-in accessibility and better SEO results.

It is now almost two decades since the Web has been invented. Initially motivated by the need to exchange documents between computer systems, the Web evolved rapidly, reshaped the notion of information systems, and changed our social interactions and cultural development. Decentralization and openness were fundamental design principles in the Web Architecture and enabled the creation of large, community-driven information spaces such as Wikipedia or OpenStreetMap. In recent years, people and organizations began to adopt these architectural principles for publishing data on the Web, resulting in efforts such as Open Government Data or Linked Data.
This course will examine technologies for building data-centric information systems on the World Wide Web, discuss the social and policy context from which they arose, show the practical applications of such systems, and go into cross-cutting issues in this context. Course work involves lectures and readings, and weekly homework assignments. In addition, there will be a semester-long project in which the students should demonstrate their expertise in building data-centric Web information systems.

Cloud9 is a state-of-the-art IDE that runs in your browser and lives in the cloud, allowing you to run, debug and deploy applications from anywhere, anytime. A complete game-changer that will change the way we develop applications forever.

This tutorial will guide you through the key steps to build, test, and publish your first Open Graph app. We will build a sample app that allows users on your website to publish stories about cooking recipes.

You've built web sites that can be used by humans. But can you also build web sites that are usable by machines? That's where the future lies, and that's what RESTful Web Services shows you how to do. The World Wide Web is the most popular distributed application in history, and Web services and mashups have turned it into a powerful distributed computing platform. But today's web service technologies have lost sight of the simplicity that made the Web successful. They don't work like the Web, and they're missing out on its advantages.

This book puts the "Web" back into web services. It shows how you can connect to the programmable web with the technologies you already use every day. The key is REST, the architectural style that drives the Web.

The HTML5 spec is 900 pages and hard to read. HTML5 for Web Designers is 85 pages and fun to read. Easy choice.

Dive Into HTML5 seeks to elaborate on a hand-picked Selection of features from the HTML5 specification and other fine Standards.

This post attempts to clarify those technical issues by providing an easy-to-read list of similarities and differences between RDFa, Microdata and Microformats. A simple table summarizing all features across each structured data syntax is listed below. Each feature is linked to a brief explanation of the feature toward the bottom of the page.

Tim Ewald explains why hypermedia is good for system integration through services –providing support for evolution, service request routing, and application recovery-, and how to build such services.

In this Synthesis lecture we provide readers with a detailed technical introduction to Linked Data. We begin by outlining the basic principles of Linked Data, including coverage of relevant aspects of Web architecture. The remainder of the text is based around two main themes - the publication and consumption of Linked Data. Drawing on a practical Linked Data scenario, we provide guidance and best practices on: architectural approaches to publishing Linked Data; choosing URIs and vocabularies to identify and describe resources; deciding what data to return in a description of a resource on the Web; methods and frameworks for automated linking of data sets; and testing and debugging approaches for Linked Data deployments. We give an overview of existing Linked Data applications and then examine the architectures that are used to consume Linked Data from the Web, alongside existing tools and frameworks that enable these. Readers can expect to gain a rich technical understanding of Linked Data fundamentals, as the basis for application development, research or further study.

The focus of this specification is readability and ease of access. Unlike the full HTML specification, this "web developer edition" removes information that only browser vendors need know.

We have traditionally analyzed collections of information or things using categories like libraries, museums, archives, content or knowledge management systems, and data repositories. The concept of an organizing system complements this categorical view with a dimensional perspective that sees these categories as sets of design patterns that reflect typical answers to questions about what is being organized, why, when, how much, who is doing the organizing, and how services are provided to interact with the organizing system. These dimensions frame trade-offs and constraints about the content, policies, and implementation of organizing systems. The primary goal of this course is to use these design dimensions to better understand traditional design patterns and their consequences, and to identify useful new ones.

For example, the thingness, uniqueness, persistence, useful lifetime, mashability, and intended uses and users of the content of an organizing system jointly determine how it is implemented and operated. We will examine how these design influences intersect, and consider what alternative designs would look like if some of these content and policy choices were to change. Furthermore, in many domains the Web has become the default implementation of organizing systems interfaces, yet we don't critically examine the implications this should have on the system itself. So we will study how Web Architecture — or the architectures and constraints implied by other metamodels and architectures such as Linked Data or WS-* services — influence decisions about content granularity and structure, how identity and provenance are supported, the kinds of interactions and services the organizing system allows, and so on.