Difference between revisions of "User talk:Mjensen"

From Evolutionary Informatics Working Group
Jump to: navigation, search
(New page: Hello, hacker world. --Mjensen ~~~~~)
 
(starting the web service saga)
Line 1: Line 1:
 
Hello, hacker world. --[[User:Maj@fortinbras.us|Mjensen]] 12:18, 17 February 2009 (EST)
 
Hello, hacker world. --[[User:Maj@fortinbras.us|Mjensen]] 12:18, 17 February 2009 (EST)
 +
 +
 +
 +
== MAJ's Web Service blog ==
 +
 +
* ''It might be helpful, or at least amusing, for others to watch someone in open combat with these concepts. As I attempt to wrap my head around them, I will attempt to regularly post my insights. I promise they will be extremely naive, but bold. --[[User:Mjensen|MAJ]] 23:13, 27 February 2009 (EST)''
 +
 +
23:13, 27 February 2009 (EST):
 +
The story so far:
 +
 +
The typical web page is one designed to accept input from humans and deliver output readable by humans. One way to think about a web service is as a [set of] web page[s] designed to accept inputs from ''programs'' and deliver output readable by ''programs''.
 +
 +
Designing a dynamic web page for humans involves "binding" controls like buttons, pulldown menus, and text fields to functions in the page's scripts, in order to provide the content the human desires. These controls have more or less standard meanings (e.g., the 'Submit' button) that have evolved into common sense by consistent usage.
 +
 +
Designing a web service involves binding particular request types in a given protocol to functions that provide content, meaningful to humans at some point, but upon delivery principally meaningful to the program that requested it. The protocol does not evolve common sense by the spread of memes; its consistency is completely intentional and built-in. The consistency of an existing protocol's methods is precisely why web communication between web agents and web services takes place via an established protocol.
 +
 +
The REST communication architecture enjoins the HTTP protocol to establish communication between agents and services. Here, however, there are only four "buttons" that can be "pushed": GET, POST, PUT, and DELETE. In practice, however, we can count on HTTP servers to understand only GET and POST. Since two buttons don't provide much scope for choosing a variety of actions, in the REST model the ''context'' in which a GET or POST request is made plays a major role.

Revision as of 00:13, 28 February 2009

Hello, hacker world. --Mjensen 12:18, 17 February 2009 (EST)


MAJ's Web Service blog

  • It might be helpful, or at least amusing, for others to watch someone in open combat with these concepts. As I attempt to wrap my head around them, I will attempt to regularly post my insights. I promise they will be extremely naive, but bold. --MAJ 23:13, 27 February 2009 (EST)

23:13, 27 February 2009 (EST): The story so far:

The typical web page is one designed to accept input from humans and deliver output readable by humans. One way to think about a web service is as a [set of] web page[s] designed to accept inputs from programs and deliver output readable by programs.

Designing a dynamic web page for humans involves "binding" controls like buttons, pulldown menus, and text fields to functions in the page's scripts, in order to provide the content the human desires. These controls have more or less standard meanings (e.g., the 'Submit' button) that have evolved into common sense by consistent usage.

Designing a web service involves binding particular request types in a given protocol to functions that provide content, meaningful to humans at some point, but upon delivery principally meaningful to the program that requested it. The protocol does not evolve common sense by the spread of memes; its consistency is completely intentional and built-in. The consistency of an existing protocol's methods is precisely why web communication between web agents and web services takes place via an established protocol.

The REST communication architecture enjoins the HTTP protocol to establish communication between agents and services. Here, however, there are only four "buttons" that can be "pushed": GET, POST, PUT, and DELETE. In practice, however, we can count on HTTP servers to understand only GET and POST. Since two buttons don't provide much scope for choosing a variety of actions, in the REST model the context in which a GET or POST request is made plays a major role.