It’s just data

NOC

Pete Lacey: A better name for SOA, then, might be network-oriented computing (NOC).  This encompasses both WS-* and REST (and most everything else from the socket level up).  We can, if we want, make SOA and resource-oriented architecture (ROA) a subset of NOC.

Kinda.  NOC encompasses REST?, That I’ll buy.  But to say that NOC emcompases protocols which, by design, attempt to abstract away the network?  Well, ... not so much.


I was trying to be as generic as possible with that term, but I take your meaning.  What do you think about “network accessible computing?”

Posted by Pete Lacey at

Hmmmm?  The problem here is that I like the notion of NOC.

Perhaps the highest level of abstraction is “computing”, which is subdivided into Network Oriented Computing and Network Incidental Computing, the latter dealing with the Network as if it were a mere inconvenience.  SOA falls mainly under the former, WS-* mainly under the latter.

Posted by Sam Ruby at

But what definition of “SOA” are you using?  That’s the crux.  Using my redefinition of SOA as an interface focused, network accessible business logic (implementable with WS-*, CORBA, etc.), then SOA too is network incidental.  If you want to redefine SOA as a computing model that accounts for the eight fallacies (implementable with HTTP), then that’s legitimate, but I don’t think it’s going to fly.

Also “computing” is too high a level of abstraction.  We can probably get away with “network computing (NC).”  Thus:

NC

Setting aside pub/sub etc.

Posted by Peter Lacey at

I guess I was giving SOA too much credit.  Also Network Independent Computing might be less incendiary than Network Incidental Computing.

Posted by Sam Ruby at

You want to dump SOA in favor of Resource Oriented Computing?! Jeez, why don’t we all go back to the dark ages of COBOL and remote procedure calls.

The point is that the user of services should be required to know AS LITTLE AS POSSIBLE about the back-end implementation. Otherwise, this is a highly sort-sighted exercise.

Sure, a ReST-ful resource oriented architecture its slightly more convenient for people who know what they’re doing... but I don’t care about them. They’re fine no matter what. Its the mediocre programmer I’m concerned with.

If you make it resource-oriented, you’re doomed to introduce interdependencies and complexities between applications that simply aren’t worth it.

Posted by bex at

You want to dump SOA in favor of Resource Oriented Computing?! Jeez, why don’t we all go back to the dark ages of COBOL and remote procedure calls.

I uhm. I, uh… I don’t know what to say.

Posted by Aristotle Pagaltzis at

Well, let me try with this bit:

you’re doomed to introduce interdependencies and complexities between applications that simply aren’t worth it.

The point of REST is to completely decouple servers and clients. All I can say about the comment as a whole is you won’t do yourself any favours to continue to opine on a topic before you educate yourself at least minimally about it.

Posted by Aristotle Pagaltzis at

Obvious? You'd think so.

Am I the only one who feels that there is an unreasonable emphaisis on naming things? Surely normal intelligent IT types can see that 1/ The REST idea of making URL’s unique references for individual states isn’t an invention but an attempt to undo...

Excerpt from Danny Angus at


The point of REST is to completely decouple servers and clients. All I can say about the comment as a whole is you won’t do yourself any favours to continue to opine on a topic before you educate yourself at least minimally about it.

Laudable goal, but I dislike the tactics... and you judge me unfairly.

I fully appreciate how ReST works well with simple and/or well-defined problems spaces... but that’s never my world. What I don’t like is the implied reliance on resources (things) over services (actions and messaging). Why should every noun (URI) have only four verbs (GET,POST,etc) in ReSTville?

What if you don’t have a clue about what resources you need to modify? What if the resources change on-the-fly based on the context of the request? The client understands the actions to take, so why should the client need to care about resources? Why should my action require me to string together a dozen requests with a dozen resources (and only four verbs), when I can use one resource and any verb?

That’s a true decoupling of server and client. I think ReST-ish APIs get close, but I feel ReST purism will lead us back to the same point we were at 8 years ago (not a good thing). Passing “action” as a parameter is considered a poor ReST practice. No thanks.

I’m growing more and more fond of the way Freebase does things... a ReST-ish API that passes data in JSON, and has an action parameter as the top-level node:

{
  "query":[{
    "id":"/common/topic",
    "properties":[{}],
    "type":"/type/type"
  }]
}

Best of the ReST and SOAP worlds, IMHO... and is a simple fit for every problems space I have. I hope they get more popular.

Posted by bex at

Passing “action” as a parameter is considered a poor ReST practice

The point is that passing “action” as a parameter is...  wait for it...

doomed to introduce interdependencies and complexities between applications that simply aren’t worth it.

If you want those interdependencies and complexities... go for it.  But experience has shown that such things don’t tend to catch on as fast as generic interfaces do.  That’s not “purism” (talk about disliking tactics and judging unfairly...), but simple observation.

Posted by Sam Ruby at

I fully appreciate how ReST works well with simple and/or well-defined problems spaces... but that’s never my world.

It works the same way in complex messy problem spaces as it does in simple well-defined ones. If you don’t see how to extrapolate from the simple to the complex, I suggest your understanding of the simple is wrong, which means you haven’t understood REST.

Why should every noun (URI) have only four verbs (GET,POST,etc) in ReSTville?

Have you heard of mashups? Caching or transcoding proxies? Client-side caches? Redirects and URL rewriting and HTTP as an enterprise service bus protocol? Google and Yahoo and other search engines? The blogosphere? None of that is possible if you throw out the uniform interface. Suddenly everything is a one-off, and every client and server are coupled to each other.

If you prefer that world, go ahead.

What if […]

If you don’t have a clue about what resources you need to modify, that’s congruent to having no clue about what actions to take; so, what then? If the resources change on-the-fly based on the context of the request, you haven’t understood how to properly decompose the problem space in terms of resources. If you think actions require stringing together a dozen requests on disparate resources, well, see previous sentence.

I feel ReST purism will lead us back to the same point we were at 8 years ago

Oh? That’s a funny number. What was in 1999?

And: purism? Loosening or abolishing any of the constraints in REST has real and practical ramifications, although varying in severity. Breaking the uniform interface happens to cause the largest extent of disasters.

Here’s my invitation: show us some functionality that you feel is too complex to express in terms of resources. After all, if your conjecture is right, it should not be possible for me or others to model it sensibly that way. Right?

Posted by Aristotle Pagaltzis at


If you don’t have a clue about what resources you need to modify, that’s congruent to having no clue about what actions to take;

I disagree there... but I think we can agree that an interface should abstract away as many unecessarry details as possible. What I see is a lot of people making ReST APIs as glorified CRUD interfaces. If your problem space is more complex than one database app, then knowing which resources to modify, and in which order, is a higher burden than knowing simply what action you want to do. I’d like people to think harder than just CRUD...

My beef with ReST has less to do with what is possible — everything is possible — but more to do what what is a natural extension of the philosophy. Hell, you can do SOA and ROA with CORBA if you want... but it’s unnatural.


Here’s my invitation: show us some functionality that you feel is too complex to express in terms of resources. After all, if your conjecture is right, it should not be possible for me or others to model it sensibly that way. Right?

One word: Move

In 4-verb ReST-ville, the concept of Moving a resource has a highly ambiguous implementation... and some ReST purists should say things should never be moved, especially if the URI is affected. Such a rule is fine for libraries, or well-defined problem spaces... but not for schemes where the top-down taxonomy is in flux, or the URI naming scheme itself is in flux, not to mention inevitable mergers, acquisitions, re-branding, etc.

In a service-oriented world, moving a resource is brain-dead obvious:

{
  "move" : [{
    "resourceId" : "foo",
    "newLocation" : "bar"
  }]
}

How’s it work? I don’t have to care!

In ReST, what’s the clear, unambiguous, 100% “pure” way to move a resource? What URIs to I need to hit, and with which verb? UPDATE? DELETE then an INSERT? What if this “newLocation” is in an entrirely different repository? Are there side effects of deleting a resource? Who handles the redirects?

Is it possible with ReST? Sure... but then doesn’t the user of the ReST API need to know the inner workings of multiple systems, instead of just one service? Its all doable, but now the user of the API has quite a burden...


Have you heard of mashups? Caching or transcoding proxies? Client-side caches? Redirects and URL rewriting and HTTP as an enterprise service bus protocol? Google and Yahoo and other search engines? The blogosphere? None of that is possible if you throw out the uniform interface. Suddenly everything is a one-off, and every client and server are coupled to each other.

Again, I disagree. Freebase mashups don’t use URIs to run queries or updates. EBay does plenty of caching with SOAP instead of ReST, and new SOA-ESBs claim to make that even easier (although I’m skeptical). Client-side caches are possible with the correct HTTP headers and parameterized URIs. Redirects are possible and easy at the application layer, which also grants better context sensitivity. Search engines work perfectly fine without permanent URIs: people move stuff, that’s why they spider so often.

And god forbid you have a blog with your title in the permalink (like this one)... what if you want to change the title and the URI to boost search engine rankings? Findability is frequently at odds with URI permanence... otherwise we’d all just be using TinyURL.

Sorry for being rude in my first post, Sam... I just got all whipped up, and slightly incoherent...

Posted by bex at

Another attempt: [link]

Posted by Pete Lacey at

Bex says “What if the resources change on-the-fly based on the context of the request?”. To me that seem to undermine one of the main points about rest, unique addressing. If you start to introduce parameterised URI’s or “server state” as a means of modifying resources you’re directly undermining the value of the URI. Better to be explicit and have more URI’s, surely?
“Findability is frequently at odds with URI permanence” why do we have to assume that each resource has to have only one URI? Just because a URI has to have only one resource doesn’t make the converse true too. Depending what API you want to publish you could map whole new URI schemes onto existing URI’s. No?

Posted by Danny at


Bex says “What if the resources change on-the-fly based on the context of the request?”. To me that seem to undermine one of the main points about rest, unique addressing.

True... but people like context sensitivity for things like security, personalization, and a bit of extra flair. What’s the unique address for today’s randomly rotating icon? Each icon could have a unique ReST-ful address, no argument there... but you need a service layer on top to choose between resources. ROA purists would force that complexity on the end-user of the API: get list of icons, use client-side JavaScript to select one, link to it. Whereas a SOA would just point the icon’s SRC to a “GetTodaysRandomIcon” service.

A somewhat contrived example, but I see that problem all over.


why do we have to assume that each resource has to have only one URI?

If you want highly ranked search results, one item can only have one URI. No duplicates, no redirects... Otherwise you get penalized for “duplicate content” by every search engine in existence. Duplicate content is the easiest way for a small web site to appear large, thus this trick is used extensively by “spam blogs.”

ReST/ROA purism means you have a choice: you can never modify a URI after it is first used, or your PageRank will fall! The former places a huge burden on early online collaboration, and the latter is simply unacceptable.

Posted by bex at

A somewhat contrived example, but I see that problem all over.

Me too.  What “service” do I invoke to get the latest ten entries on your weblog?  Or the top six tech news items on CNN?  Or the top ten search results for "SOA"?

By the way, moving the resource ID outside of the payload enables redirection; not the other way around.

Posted by Sam Ruby at


What’s the unique address for today’s randomly rotating icon? ... A somewhat contrived example, but I see that problem all over.

I just thought of a better example: ads targeted to users based on credentials and search history. Highly context sensitive, highly stateful, and the key to all moneymaking on the web.

A resource-oriented purist would cry... whereas a service-oriented purist wouldn’t blink.

Thus, I think its dangerous to adhere to a ROA philosophy. I think its better to think service-oriented, ditch most of the complexity of the WS-* stack, and cherry-pick good ideas from the ReST camp only when it helps a specific problem.

Posted by bex at

ads targeted to users based on credentials and search history

amazon.com; you should try it some time.

Posted by Sam Ruby at


amazon.com; you should try it some time.

hehehe... so I guess the question is, what bits of ReST purism went out the window in order to implement that?

If you don’t pass the resource ID in the payload, in order to enable redirection/personalization/etc, then I’d argue that the “resource” is not the primary abstraction. The top-level abstraction is “the thing which selects and processes my resources.”

In my mind, that’s what a “service” is all about.

Posted by bex at

In my mind, that’s what a “service” is all about.

It also called a resource.  We should have more of them, and not hoard them as if they were precious.

Posted by Sam Ruby at

Thus, I think its dangerous to adhere to a ROA philosophy. I think its better to think service-oriented

It would help if you actually demonstrated an understanding of the ROA philosophy.

A resource-oriented purist would cry... whereas a service-oriented purist wouldn’t blink.

Hmm... wait a minute.... no... wait... let’s see.... nope, no tears.  I can actually think of several very simple ways of accomplishing this.

ads targeted to users based on credentials and search history

Simple enough.  Server-side negotiation and simple auth mechanisms would handle this nicely.

In 4-verb ReST-ville, the concept of Moving a resource has a highly ambiguous implementation

It’s a good thing that REST isn’t limited to 4 verbs then.  REST says only that the interface should be consistent and uniform across all resources.  There is nothing that says new verbs cannot be introduced.

RFC 2518 Section 8.9.5:

>>Request

   MOVE /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html

   >>Response

   HTTP/1.1 201 Created
   Location: http://www.ics.uci.edu/users/f/fielding/index.html

Seems simple enough to me. 

What if you don’t have a clue about what resources you need to modify? What if the resources change on-the-fly based on the context of the request?

As was mentioned elsewhere in this thread, this is a modeling issue that requires shifting some of the complexity around a bit.  No one has ever claimed that REST eliminates all of the complexity inherent in many types of applications, only that it shifts some of that complexity around so that applications and data are more scalable, robust, cacheable, etc.  The trick is in finding the right way of modeling your application as resources, not avoiding resources altogether or claiming that resource-orientation is bad.

today’s randomly rotating icon

It’s interesting that every day I visit http://dilbert.com, there’s a new comic displayed.  It’s also interesting that every time I go to http://planet.intertwingly.net, there’s a new set of entries for me to read.

Posted by James Snell at


It’s a good thing that REST isn’t limited to 4 verbs then.

I’m glad you and some think so, but others disagree, even Wikipedia is conflicted. Roy Fielding says all you need is POST and GET, so should I trust him, or you, or Sam’s new book?


It also called a resource.  We should have more of them, and not hoard them as if they were precious.

I recall a quote (cant find it at the moment), about how IDEs, toolkits, languages, and programming philosophies genuinely affect the thought process of a developer...

If you see the world as nothing but “resources” that return “representations” of data, doesn’t that limit what you can do? Again, not that anything is impossible... but the point of an architectural philosophy is to ensure that thoughts, discussions, and solutions be instinctive. Isn’t a “service” that wraps “resources” a far more clear and open-ended way of thinking about all possibilities? Isn’t ReST’s obsession with resources to blame for all the CRUD-wrappers calling themselves APIs?

I believe so... although I’m probably the minority.

Hopefully Pete Lacey will come up with something good.

Posted by bex at

so should I trust him, or you, or Sam’s new book?

The statements you point to aren’t in conflict.

languages ... affect the thought process of a developer

Sapir–Whorf hypothesis

Posted by Sam Ruby at

If you see the world as nothing but “resources” that return “representations” of data, doesn’t that limit what you can do?

No. It only limits the ways in which your system can be structured in order to attain particular desirable system properties.

Posted by Aristotle Pagaltzis at

In ReST, what’s the clear, unambiguous, 100% “pure” way to move a resource?

That’s a no-brainer: express it in terms of operations on resources. Make the location itself a resource and use PUT to update it.

In case you are going to wonder “how can I know the address of the location resource?”, the answer is “see hypermedia constraint.”

Of course you can introduce a new verb to handle that – but the number of implementations that understand your particular interface shrinks ever faster with every new verb you add.

Posted by Aristotle Pagaltzis at


In ReST, what’s the clear, unambiguous, 100% “pure” way to move a resource?

That’s a no-brainer: express it in terms of operations on resources. Make the location itself a resource and use PUT to update it.

Thanks... but then why does Roy Fielding say that all you need is POST and GET for ReST? I’ve read numerous examples of how it could be done, but few emphasize how it should be done. Ambiguity amongst the passionate usually leads to trouble...

For the sake of clarity, I’d like to do away with the concept of a web-enabled resource once and for all. ReST fans define a resource in an interesting way... I’ll user the one from the Atom Publishing Protocol RFC, which you are probably all familiar with:


Resource - A network-accessible data object or service identified by an IRI, as defined in [RFC2616]

One problem: there’s absolutely no difference between a network-accessible data object and a service, and believing in a distinction causes trouble.

Any network enabled data access (like GET) by definition has to go through a server... even the most basic GET request has dozens of layers for security, redirection, error reporting, etc... its not as simple as local data access, as ReST folks often warn us...

Since there’s no difference, doesn’t that mean everything on the web is a service? Then, if resources can only be services, isn’t the “resource” abstraction superfluous? Shouldn’t we define the entire web as a HTTP based SOA, and not a ReST based ROA? I could go on and on...

I’m fully open to the possibility that I’m an idiot... but that’s how I see things.

Posted by bex at

Compare the following statements: two is the bare minimum, four is a comfortable median that fits most problems, you can define as many verbs as you like, and you probably shouldn’t define any more than you have to.  These statements are not contradictory.  To the contrary, they are consistent and reinforce one another.

Just like a photon is both a particle and a wave, Google is both a resource and a service.

Either way, the rest “fanatics” as you seem prone to portray them  merely believe that a system composed of uniform interfaces and lots of identified resources is often an easier one to understand and reason about than one composed of custom operations and few “endpoints”.

Put another way, if you put a large system under a microscope, you could undoubtedly make local “improvements” by introducing custom interfaces, but eventually the complexity that you create in doing so will catch up with you.

Posted by Sam Ruby at

there’s absolutely no difference between a network-accessible data object and a service, and believing in a distinction causes trouble.

Sorry, that’s wrong. Let’s be absolutely certain what we’re talking about here because semantics are a very tricky thing.  I think that we can agree that there is a significant difference between REST-style applications and SOA-style applications as both are typically implemented.  The former being exemplified by things like Atompub, the latter by things like WS-*.  It is possible to call REST-style things “services”; and if you choose to do so then fine, whatever.  But calling a REST-style thing a “service” does not make it similar to other types of things that are also called “services”.

Thanks... but then why does Roy Fielding say that all you need is POST and GET for ReST? I’ve read numerous examples of how it could be done, but few emphasize how it should be done. Ambiguity amongst the passionate usually leads to trouble...

There is no ambiguity.  To move a resource you can either a) use a GET-DELETE-PUT combo, b) use MOVE or c) use POST.  Using option a means using multiple requests to two different resources with no transactional semantics. Using option b means a single request that shifts the complexity of the operation over to the server.  Using option c means relying on the application to do the right thing and will likely mean less interoperability between implementations.  The choices are very clear and unambiguous.  Alternatively, with something like SOA/WS-*, there are no standardized operations for “move”, so you end up having to depend on each individual implementations xml namespaces, choice of method names, choice of parameters, error reporting mechanism, etc. 

If you see the world as nothing but “resources” that return “representations” of data, doesn’t that limit what you can do?

No. All it does is require us to think differently about what it is we want to do.

Isn’t a “service” that wraps “resources” a far more clear and open-ended way of thinking about all possibilities?

No, because it’s a meaningless distinction.  At one level anything that exposes capabilities that some other thing can use is a “service”.  It is far more meaningful to make distinctions between the different types of services; e.g. REST-style vs. SOA/WS-* style.  This gets to the heart of what the NOC concept is trying to achieve.

Posted by James Snell at


Either way, the rest “fanatics” as you seem prone to portray them merely believe that a system composed of uniform interfaces and lots of identified resources is often an easier one to understand and reason about than one composed of custom operations and few “endpoints”.

Reasonable... although I sense danger. Assume 4 options: ten endpoints with two operations each, five endpoints with four operations, two endpoints with ten operations, or one endpoint with 20 operations. All have merits, depending on your goals and the logical groupings. An SOA purist would be fine with any of them, but the ROA purists I know balk at anything besides the first option, regardless of “need”... although that could be because their world is heavily RoR/ORM.


It is possible to call REST-style things “services”; and if you choose to do so then fine, whatever.

Its not my choice... if you have a better definition for “resources” and “services” than are found in the RFCs or Wikipedia, I’ll be happy to use it.


It is far more meaningful to make distinctions between the different types of services; e.g. REST-style vs. SOA/WS-* style.  This gets to the heart of what the NOC concept is trying to achieve.

I agree, and look forward to more NOC definitions. But from my perspective, ReST services and SOA-/SOAP-/Web-services are pretty darn similar... and initially NOC was unfairly grouping SOA with the “losers” like CORBA/DCOM/EJB.

Posted by bex at

An SOA purist would be fine with any of them

s/be fine/profess to be fine/.  But look closer and see what they actually recommend.

Posted by Sam Ruby at

Unrelated Question:

Which is a better idea for web service discoverability: Microformats, or something like an “alternate” link to a JSON formatted “service descriptor"? Sort of like a JSON-ish WSDL, but less weird.

Microformats are neat because you can embed the required "POST” data in the display of the info... whereas JSON-ish WSDLs probably are more expressive. But ReST folks probably don’t have to care as much about that.

Posted by bex at

Re: "ReST folks": don’t lump prematurely.

Some would argue for WADL, others for RDF, others for RDDL others for GRDDL, some for some combination of the above, and still others would argue for the data formats themselves to be self-descriptive.

Posted by Sam Ruby at

But from my perspective, ReST services and SOA-/SOAP-/Web-services are pretty darn similar...

Well, they both do utilize HTTP and POST but that’s about where the similarities end. 

and initially NOC was unfairly grouping SOA with the “losers” like CORBA/DCOM/EJB.

SOA, despite it’s relative advantages relative to CORBA/DCOM/EJB is born from the same mold and philosophy of each.  It may be better than those, but it still deserves to be grouped right along with them.

Posted by James Snell at


But from my perspective, ReST services and SOA-/SOAP-/Web-services are pretty darn similar...

Well, they both do utilize HTTP and POST but that’s about where the similarities end.

I’m speaking of the only abstraction that matters: how I consume it over the network. Back end implementation details aside, what’s the difference?

SOA purists insist that everything is POST. However several implementations allow GET with parameterized URIs since its simple to consume. ROA purists say URIs should not be parameterized. However, from the above discussion I take it that there’s some disagreement on this point... although “action” is HUGELY frowned upon.

So, a “fuzzy” implementation of either allows parameterized URIs with HTTP GET to return data. SOA is usually SOAP formatted XML, whereas ROA has multiple formats. Regardless, my consumption app will look pretty darn similar... Unless you believe that any SOA must include WSDLs, tight data binding, objects, etc., but I hate those things.

Posted by bex at

ROA purists say URIs should not be parameterized

No, URIs should not contain the verb.  The URI is the parameter.  There’s absolutely nothing wrong with querystring params so long as the verb is not included. e.g. POST /some/thing?action=delete is just plain silly.

Posted by James Snell at

how I consume it over the network.

Exactly. REST web apps use HTTP as the application protocol. Big Web Services use it merely as a firewall-piercing, efficiency-reducing transport protocol atop TCP, with custom one-off application protocols layered thereupon.

Posted by Aristotle Pagaltzis at


e.g. POST /some/thing?action=delete is just plain silly.

I’ll agree DELETE /some/thing is preferable in this case... but what if you need 10 verbs? Is FOO /some/thing really so much better than POST /some/thing?service=foo ? All browsers know not to refresh a POST, but what’s it supposed to do with a FOO? How many of them know not to refresh a PUT? If you put the verb as a parameter, and always use POST for state change, you can safely use the same API just about anywhere... crappy older browsers, or buggy new ones.

Of course, this encourages verb proliferation... but I’m not convinced that noun/resource/object proliferation is preferable. Got any links?


REST web apps use HTTP as the application protocol. Big Web Services use it merely as a firewall-piercing, efficiency-reducing transport protocol

hehe... I’m reminded of ETech 2002: “calling SOAP a firewall-friendly protocol is like calling it a skull-friendly bullet.”

Anyway, if all you do is what HTTP supports, then HTTP is the application protocol. But if you want to do anything that HTTP doesn’t inherently support, you’re using HTTP as a transport protocol... even if you’re using ReST. Ever use custom verbs, custom error messages, or custom error numbers in ReST?

Posted by bex at

but what if you need 10 verbs

Part of the whole point is that you probably don’t really need 10 verbs.

If you put the verb as a parameter, and always use POST for state change, you can safely use the same API just about anywhere

You’re missing the point.  REST is an architectural style that when followed provides a number of benefits that are more difficult to realize when you don’t follow it.  No one is saying that the other ways of doing things don’t work, just that they don’t work as well and that they typically lead to significant unintended consequences.

Posted by James Snell at

if you want to do anything that HTTP doesn’t inherently support

Then you shouldn’t be using HTTP. (Cf. XMPP.) But anything that can be modelled as RPC-over-HTTP can be modelled in terms of resources without loss of any desirable properties.

Posted by Aristotle Pagaltzis at

[link]...

Excerpt from del.icio.us/lsdr/rest at

Towards a better network programming taxonomy

Previously I defined and redefined some terms to be used when discussing networked systems. With feedback from Sam Ruby, Josh Haberman (in the comments), and Steve Jones, plus smoe more thought on my part, I would like to present a more refined...

Excerpt from Pete Lacey's Weblog at

Add your comment