less of a test

This is less of a test. On second review, my stylesheet is coming togehter quite nicely, and I think I’m ready for jsled.digital.presence 2.0 to be launched… Specifically, I’ve got ~50% more FOAF than before, and a new personal page, which I haven’t really had for a while. The twiki will be relegated to it’s … Continue reading “less of a test”

This is less of a test. On second review, my stylesheet is coming togehter quite nicely, and I think I’m ready for jsled.digital.presence 2.0 to be launched…

Specifically, I’ve got ~50% more FOAF than before, and a new personal page, which I haven’t really had for a while. The twiki will be relegated to it’s rightful role, and obvousily I’ve got some MT lurvin’ in effect.

So … I’m at the point other people were at ~3 years ago; go me.

Testing

Testing. This is primarily a test in order to get some content, such that I can… rebuild site fetch page hack CSS create stylesheet for basic site. It just needs to NOT be fugly.

Testing.

This is primarily a test in order to get some content, such that I can…

  1. rebuild site
  2. fetch page
  3. hack CSS
  4. create stylesheet for basic site.

It just needs to NOT be fugly.

numerous verbs and uniform apis

Wish I’d been at what sounds like a downright bloody battle down under. :) Responses to some of the points: The really interesting stuff came about when they were challenged about the REST aspects of the application. Again the standard REST attack of uniform interface good/rpc bad came out, amongst others. This is a flawed … Continue reading “numerous verbs and uniform apis”

Wish I’d been at what sounds like a downright bloody battle down under. :) Responses to some of the points:

The really interesting stuff came about when they were challenged about the REST aspects of the application. Again the standard REST attack of uniform interface good/rpc bad came out, amongst others. This is a flawed argument in my opinion for a number reasons:

1. Malicious payloads can be propagated irrespective of your transfer semantics, and insecure code can be executed whether your service is RESTful or not. The “safe” nature of the Web doesn’t get round buggy back-end implementations.

This must be in response to something said at the event … ?

2. We’re past the RPC stage of Web Services, and we’ve been past it for a while now. Message to the REST community – stop telling us that we’re playing catch up and see what’s really been happening on our side of the fence.

Fair enough.

3. The uniform API isn’t uniform. For each HTTP verb (GET, POST, PUT, DELETE) the accompanying message can be arbitrary. That is, you can’t POST a purchase order message to a REST service that expects to receive a circuit diagram. At some point you have to understand the messages.

There are two parts, here: 1. Application Programming Interface 2. Messages carried over API.

In RPC, both are arbritary, which has a known set of problems in a networked environment crossing trust boundries. REST seeks to limit one — the API — and let the complexity be managed in the messages. Moreover, REST encourages a well-known set of widely-agreed-to message types.

More importantly, however, by fixing the verbs — the API — you have a much better chance of being able to intermediate in those operations. Because the semantics of the API operations are fixed, you actually have a chance to get in the middle of the communication.

4. The HTTP verbs are too numerous. Sure only GET and POST are usually used, but these are too numerous and too protocol specific too. You really only need a processThis(SOAPMessage) method on every service if you’re in a true asynchronous Web Services environment. Granted if you want synchronous communication, that might need to return a SOAPMessage too.

The fact is that regular Web Services have a far more uniform interface than the REST style. I’ve laid down the challenge before, but you can’t get much more uniform than one (imaginary) verb, can you?

Mark says it better, but here’s my response:

That’s a red herring. The fact is that if you only have a unconstrained ‘do stuff’ method, you’re in a far weaker position than HTTP’s 4(-6) well-defined verbs. At thet same time, if you have an arbritary set of undefined verbs, then you’re not very well off, either.

The real issue is the definition of meaning of the API operations. GET, POST — and even PUT and DELETE — have very specific defintions and requirements on their behavior. And beyond that, there are a set of headers which further affect how those verbs behave in well-specified, well-thought-out and well-tested ways. This is important because it enables a class of tools to operate over the traffic, as well as providing a necessary semantic base on which other specifications to be based.

quitting smoking

(or: Fuck! Ass!) Don’t let anyone tell you that quitting smoking is easy. I spent Sunday, Monday and Tuesday either unable to focus on anything for more than 2 minutes, or drunk to escape that fact. Which is really fun when you’re trying to get work done — and get frustrated when you can’t get … Continue reading “quitting smoking”

(or: Fuck! Ass!)

Don’t let anyone tell you that quitting smoking is easy.

I spent Sunday, Monday and Tuesday either unable to focus on anything for more than 2 minutes, or drunk to escape that fact. Which is really fun when you’re trying to get work done — and get frustrated when you can’t get work done.

Wednesday was the first day that I could actually plod along and do stuff, and even then it’s still not a cakewalk.

Yesterday still wasn’t so hot.

Today is better, but still not great.

Anyways. I can start to smell things again — thank god I don’t live in SF anymore. ;) I think I’m going to start cooking things a bit more.

small things

So I just went through my Small Things box to find a old pair of red/blue glasses so I could view http://antwrp.gsfc.nasa.gov/apod/ap040108.html; I didn’t find them, but I did find the Certificate of Title to my car, which I thought I lost. So I guess I win.

So I just went through my Small Things box to find a old pair of red/blue glasses so I could view http://antwrp.gsfc.nasa.gov/apod/ap040108.html; I didn’t find them, but I did find the Certificate of Title to my car, which I thought I lost. So I guess I win.

links

Synergy / http://synergy2.sf.net/ Multi-{platform,machine} keyboard/mouse transport; use two desktops from one machine. Nomic game on c2 wiki / http://c2.com/cgi/wiki?NomicGame Why is it that even though I’ve spent time looking around the c2.com wiki, I’ve never seemed to see it all? Gnome Desktop integration bounties / http://www.gnome.org/bounties/#categories An idea who’s time has come. With all this … Continue reading “links”

WinFS and IPC

A friend pointed me to http://www.ozzie.net/blog/stories/2003/11/14/640kbOughtToBeEnoughForAnyone.html… Very interesting. I’ve been reading good things about WinFS, and generally about other facets of Longhorn, since the PDC. And now micros~1 is releasing the Word and Excel XML schemas… with perhaps-not-unreasonable licenses. I don’t have a lot of stock with the “official” WS-* specs or technology stack they’re … Continue reading “WinFS and IPC”

A friend pointed me to http://www.ozzie.net/blog/stories/2003/11/14/640kbOughtToBeEnoughForAnyone.html

Very interesting. I’ve been reading good things about WinFS, and generally about other facets of Longhorn, since the PDC.

And now micros~1 is releasing the Word and Excel XML schemas… with perhaps-not-unreasonable licenses.

I don’t have a lot of stock with the “official” WS-* specs or technology stack they’re creating, so that analogy is lost on me. ;) His analogy is empty: all those awesome Amazon WS efforts are based on REST, not SOAP + WS-*…

Providing the infrastructure to get applications storing structured, relational data sets is a GoodThing. I have a bad feeling there will be an extra level of useless complexity to it, though.

I don’t think that it’s going to be useful. Programs are only as useful as they provide services — not data — to other programs. All those cool tools that he mentioned should be HTTP servers, and speak to eachother [and to the OS] via well-defined and common [RESTful ;)] interfaces.

The GNOME people almost got it right — but chose fsck’ing CORBA as their IPC mech. tsk-tsk-tsk. Especially because at the time it was clear HTTP was winning. Ah, well — I didn’t see it either.

Perhaps a storage mechanism can assist in that, but if it’s only at the data-transfer level, interesting functionality [mostly queries, I’ve been thinking, but also application semantics and manipulation constraints] will need to be re-implemented all over the place. And that’s the hard part.

First Snow

It has snowed in the past … even over a month ago. But this is the first time it hasn’t immediately melted. I give you: First Snow.

It has snowed in the past … even over a month ago. But this is the first time it hasn’t immediately melted. I give you: First Snow.

[First snow!]

We turned on the radio this morning to hear of schools being closed. Crazy.

I wonder if this will prompt Magic Hat to start brewing their seasonal Heart of Darkness Stout. Given they’re located in So. Burlington [just down the highway], perhaps that’s a good indication of what comes next.

REST

Comments regarding plightbo’s recent anti–REST posts… Objects vs. Resources There is a fundamental difference between objects and resources, and it’s really important. Objects are data + behavior, whereas resources are just data [and links to other data, if you’re smart]. It’s the associated behavior that makes things scale badly. There is a world apart from … Continue reading “REST”

Comments regarding plightbo’s recent antiREST posts…

Objects vs. Resources

There is a fundamental difference between objects and resources, and it’s really important. Objects are data + behavior, whereas resources are just data [and links to other data, if you’re smart]. It’s the associated behavior that makes things scale badly. There is a world apart from objects: the semantics of the data itself are of primary importance, not the semantics of an interface to that data.

Tools

There are plenty of tools for RESTful systems … you’re just taking them for granted…

All these tools solve very tangible problems, and have been shaken out over a long time. The tools for some other technologies seem to exist primarily to solve problems or reduce work created by the technology itself… though in some cases they do solve a higher-order problem, and are useful. WSDL is a good example: a reasonable resource/interface-description language, and, hey, it can be applied to RESTful interfaces very well.

Tools aren’t overlooked because of religion — they’re overlooked because they defocus developers from solving the real problem-at-hand rather than the details around the technology brought to bear in hopes of solving the problem at hand.

CRUD operations masked over a database

How is GET http://www.google.com/search?q=important+search+term a “simple CRUD operation thinly masked over a database”?

Or a POST that buys you a ticket on an airplane and moves you across the country?

It’s not that the operations or verbs or especially their implementation is simple. It’s that there’s a simple interface to them. REST requires a constrained interface, not a constrained implementation. In fact, it enables the implemention to grow unconstrained by a tightly-coupled interface. It’s another form of encapsulation — but of the procedural implementation, not the data. In fact, a view of the data is given primary importance.

Business tasks

You’re correct in saying that business people don’t care about the implementation details … but only until you tell them “no, we’d have to spend 6 months re-architecting the system for that.” Our job as engineers is not only to implement the currently-required functionality, but also to keep the system healthy and able to grow. They also don’t care what language we write it in [although they do from time to time], but we choose what language to write it in for a variety of time/skill-set and growth concerns. And with respect to this thread, I know which technology is available in nearly every language we would every even consider working with, and it isn’t SOAP, RMI or XML-RPC…

There are some things that require foresight, and can’t be designed for the moment; that’s why it’s called architecture, and not design. APIs are one of them, and networked APIs even more so, especially with the expectation that the system will grow very quickly.