Design

REST -only links or no?

Ebenezer Ikonne — Tue, 01 May 2007 15:07:50 GMT

REST touts that a "progresses through an application by selecting links (state transitions) resulting in the next page....

To borrow from a commonly used example, if I have a web service that "gets a list of parts", the URI to get the parts would look like this: http://www.parts-depot.com/parts and the "response" contains a list of links to the individual parts like this: <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>

For additional information, I would have to "select" the link to "GET" information on the part.

What consumer application really wants to iterate through a list of links to get part detail information (other than a user interface)?

The Astoria samples are more liberal and actually return detail information for each product that exists (a URI is included also):

<QuantityPerUnit>10 boxes x 20 bags</QuantityPerUnit>

<Discontinued>False</Discontinued>

</Product>

<ProductName>Chang</ProductName>

<QuantityPerUnit>24 - 12 oz bottles</QuantityPerUnit>

<Discontinued>False</Discontinued>

</Product>

</Products>

</DataService>

This just seems wrong to me and state transitioning seems to be shot. In other words, I think it becomes less about REST and more about HTTP and data formats. Maybe it's hi-REST versus low-REST?

Is Software Development Really Hard?

Ebenezer Ikonne — Wed, 31 May 2006 10:04:00 GMT

Rocky blogs that 98% of the systems being built out there are "trivial" or at least can be solved by "trivial" solutions. Is this really the case? He also contends that most applications are a "viewer (form, page, screen)" over data and development tools such automat this, attributing unecessary complexity to tool vendors, framework builders, architects etc.

I actually disagree with his assessment on the distribution of complexity. My developers spend much more of their time behind the screen than in it. I've worked on enough projects to know that there are a fair share of applications where more interesting things happen when a user clicks the "Ok" button.

Understanding the business problem that needs to be solved (deployment model, update strategy, functionality, performance requirements, scalability, user interaction, configurability, integration etc) drive the tools and methodologies that should be used. A decent understanding of tools and methodologies are required in order to effectively use them. It's not a secret that a lot of software projects fail due to a lack of understanding of both the problem domain and the toolset/methodologies required.

I cringe when folks with influence imply a panacea of sorts for software engineering based on a subset of scenarios. Each situation has to be studied in isolation. While there may be reusable "patterns and practices", in a lot of cases, these need to be "tweaked" to solve the problem. If your application is simply forms-over-data, build it in the simplest manner possible!

Why I Hate Frameworks

Ebenezer Ikonne — Thu, 09 Mar 2006 09:03:00 GMT

Via Don Box, I stumbled on this Why I Hate Frameworks. Quite humorous and actutally a good read.

Frameworks exist at multiple levels e.g. in my opinion System.IO is a framework. However, just like everything else, things can be overdone which leads invariably to Technology (maybe now Framework?) Overload.

What do you think?

All things pragmatic...

Ebenezer Ikonne — Sun, 19 Feb 2006 22:47:00 GMT

So Mr.Box posts Pragmatics and he's generated quite a buzz. Bottom line (unfortunately) is that something has to ship, and with the toolsets available SOAP seems the easier/easiest option right now. Clemens has a series of articles that I need to read up on to see how “Indigo can do REST”. I wonder how many .NET based REST implementations exist out there? If you know of any please share.

Interesting stuff huh?

The World of SOA

Ebenezer Ikonne — Wed, 14 Dec 2005 22:22:00 GMT

I saw this post today and I was blown away by the number services that will be available, 30,000. Wow.

Two forces of nature

Ebenezer Ikonne — Mon, 28 Nov 2005 19:48:00 GMT

Udi, once again posts a brilliant article here. Specifically in Microsoft-dom, “Connected Systems” is definitely the mantra. However, I look at this slightly different from how Udi looks it. I take it to mean: How Can We Connect Everything and Anything with Everything and Anything in the simplest way possible. For some, this is a big issue and for others (due to whatever requirements they have), it isn't.

I think you need to figure “how to connect” before figuring out “what happens when I can't” and I believe “Connected Systems” tries to solve the former problem.

Having said all this, most developers developing distributed proprietary systems don't take time to to think about what would happen if the “other side” is not available. Then again, most developers don't think about “what if the data is null” or “the file does not exist”. Is this really a “Connected Systems” issue? I don't think so.

How many is too many?

Ebenezer Ikonne — Mon, 28 Nov 2005 19:37:00 GMT

Udi posts So many Dlls, so little time. Working on a project where there was a class to dll mapping, I can agree to some degree with what Udi states. However, I believe becoming to granular also has its disadvantages and if not careful instead of referencing one dll with a couple of classes, you might end up referencing ten dlls with a class each.

I think that related classes should be wrapped up into a single project and assemblied as a single unit. Interfaces should be used to broker communication when a circular dependency might be introduced.

Classic.

Ebenezer Ikonne — Wed, 23 Nov 2005 12:50:00 GMT

Everyone should read this: What are you?.