ToddFredrich.com RESTful/Platform APIs and Examples, Tutorials and the Software Craft. Mostly…

30Sep/141

The Commoditization of the User Interface

Posted by Todd

The public face of a business system is its user interface (UI)--the part the end-user sees. Businesses often think in terms of user interface design. Many times they also consider it the facet that gives them an edge in their market (the "killer app").  Being overly concerned with the UI first, focusing on what the web interface or mobile application looks like, often means duplicating complicated business logic across those UIs.  This makes the user interface very difficult to maintain and morph over time as business needs shift.

The Problem

Mobile-first is a term that's created a lot of buzz lately.  So much so as to render the term largely meaningless.  However, it does point to a great need: the need to revise or even provide new user interfaces for business systems as channels change and new ones become available. But with all that complicated business logic captured in Web applications, JavaScript, native IOS and Android applications, it's very expensive to start over when creating a new user interface.

We need to be able to throw UIs away and start over with minimal cost. Or create new UIs for new channels and/or devices without duplicating all that business logic.  The real asset must be the business logic encapsulated in our back-end business systems.  These systems should provide the ability to be UI agnostic. In other words, the face of the business system (e.g. user interface) should be able to change drastically over time without compromising business processes and should have minimal cost.

This is not the case today.

Enter the Shiny REST

APIs should encapsulate both processes and data

APIs should encapsulate both processes and data

There's a shiny new kid on the block called REST APIs. Maybe you've heard of them? They promise easy integration, new business partners, reduced time to market, reduced development cost, increased revenue models, more income, improved creativity & innovation, architectural coolness, singing angels, and maybe even the voice of God saying, "Well done!" At least if you listen to the hype.

In most Web applications, such as Java/JSP stacks, the user interface is intrinsically linked to the back-end business logic and right down to the database. And while service-oriented architectures (SOA) encourages loose coupling between components, the focus is on behavior not data. Putting a UI on those processes is difficult.

The promise of REST APIs is largely that business logic and data is encapsulated behind a suite of HTTP resources. However, at the time of this writing, most businesses seem to be looking at REST APIs because they're new and shiny, much like businesses "needed" a website to be successful in the late nineties.

The promise has yet to be realized!

Business systems are both data and process.  The problem with most Web APIs (we can argue whether they're truly REST-ful later) is that they only expose data to the outside world, excluding business processes altogether.  Typically, the sequence of API calls and details about state changes are shared out-of-band in documentation about the API and are not part of the API request/response cycle itself.  This inhibits business logic from being part of the API and pushes business logic into any user interface written on that API.

This is not optimal, in case you were wondering.

To realize the dream, an API must encapsulate both processes and data!

An API for Processes?

Modeling processing within a REST/Web API may seem foreign at first. At least until we consider that HTML has supported the concept for years, with links, inputs, and forms.  Leveraging these concepts within a REST API (right in a JSON payload), we can take our APIs to the next level, encapsulating both data and business logic.

In essence, by using links and forms in our REST APIs, our APIs become more like state machines. These state machines, with both data and behavior (transitions), can model extremely scalable, maintainable, arbitrarily-complex business processes.

This is the realization of Roy Fielding's "hypertext as the engine of application state" (HATEOAS) constraint of REST.

So how do we model a data and behavior in an API? In essence, it's media types that enable us to expose links, actions and forms within our API payloads. Which, in turn, enable us to model complex business processes without moving that business logic to the client.

State-Machine APIs

As mentioned, a typical API response today will only contain data. More advanced ones expose links (say via the HAL media type). Even more advanced representations, capable of modeling state machines, contain more-than just links and data, adding actions and forms. Media types such as the SirenCollection+JSON, and HALe are good examples.

Consider the following simple state-machine diagram.

Simple State-MachineIn it are two states, state A & state B. The state-machine changes from state A to state B when event C occurs (note that the state-machine must be in state A for event C to occur). Additionally, the state machine goes from state B to state A when event D occurs.

A Lighting System Example

If the above state machine is implemented by a REST API with states A & B represented by JSON and the events are generated by actions on that API.  Let's say the API represents a lighting system with off & on states (representing state A and B, respectively), with events of turn-on and turn-off (representing events C and D, respectively).

Initial state A of off might be represented in JSON (using my own invented state-machine media type) as:

{
    "status":"off",
    "_actions":{
        "turn-on":{
            "href":"http://api.example.com/lights",
            "method":"POST",
            "data":{
                "status":"ON"
            }
        }
    }
}

From this representation, we know that the status of the light is off and that we have the capability to execute the turn-on action by calling:

POST /lights
HOST: http://api.example.com
{
    "status":"ON"
}

Whereupon the API makes the state transition and responds to the turn-on action with something like the following:

{
    "status":"on",
    "_actions":{
        "turn-off":{
            "href":"http://api.example.com/lights",
            "method":"POST",
            "data":{
                "status":"OFF"
            }
        }
    }
}

 

Conclusion

Although the above example is extremely simple, it illustrates the key point that a user interface for our lighting system could be created without any business logic since the API contains all the possible actions that the user interface can make.

There's no URL construction within the UI code base, no if-then-else logic to determine possible actions based on the value of the status property.  It only needs to utilize the possible actions in the _actions property.

This is very powerful. APIs of the future will enable the commoditization of the user interface by encapsulating both data and business logic.

What are your thoughts? Enter a comment below about your thoughts and experiences.

16Dec/090

The Internet vs. Brick-and-Morter (or The Times They Are A Changin’)

Posted by Todd

I continually hear businesses complain about how Internet companies are stealing their business--that it just isn't cost-effective to do business any more. Boo Hoo!

Here's a story for you. As an amateur photographer, I am constantly in the market for equipment upgrades and accessories to maximize and optimize my photographs and experience. I have window-shopped several of the local establishments here in Denver, both their new and used departments. I like to patronize the local shops for several reasons. First of all being convenience, then because they ARE local and I like to see businesses succeed.

The other day on impulse, I bought a used lens from one of the local Denver shops at a reasonable price. It wasn't a steal, I could've gotten it cheaper elsewhere (keh.com in particular), but they insisted on the price and they were offering a six-month warranty. Cool, I couldn't really quibble over $25 for a $850 purchase! Especially when there's lag-time and shipping costs involved from an Internet company.

The next morning, dork that I am, I got cold feet as I need to sell a few things before I can truly fund a hobby purchase of this nature (fellow photographers understand what I mean) so I attempted to return my recent acquisition not even 24 hours later. That's when things got ugly.

In attempting to make a return to this local establishment, I was presented with a statement on the bottom of my own receipt: store credit only on returned items over $100 in value. Right--who reads their receipt? And at that point it's too late! Besides, what can you buy in a camera store for less-than $100? Then I was presented with a 15% restocking fee (about $120). Unacceptable. I negotiated the fees down to about $40--they had to be compensated for the Visa fees--still feeling that was too much. I ended up getting a check from them, negotiating the fees down to $20.73 to compensate them for one-way Visa charges. It was a MAJOR hassle in my opinion.

Now if I'd bought the lens from one of the reputable photo dealers on the Internet, keh.com, adorama.com, or bhphoto.com, I would have had at the very least a 7-day no-quibble return window. But also would've been out return shipping. However, I wouldn't be hassled over why I was returning it--whether it was a problem with the equipment or not, etc. Neither would I be presented with a restocking fee nor would I have to quibble over Visa fees!

It is interesting to note that ALL of the fore-mentioned companies have a brick-and-mortar presence. I'm sure they still pay Visa fees. And I'm sure people purchase items to shoot an event or stuff around the house then return them.

So I ask you... do you think I'll be returning to patronize that particular local camera store? Do you think I'm being unfair? I think businesses need to catch up with the times and consider that local stores CAN compete when they offer truly great customer service, convenience and friendliness. This business offers very little, if any, of that. Bummer.

As far as I'm concerned, if you want to stay in business now days, you need to pay attention to what's going on, how you fit into that, and what unique benefits you provide--focus on those, providing even more of what you're good at.  Or you can be stingy, focused on lack, and go out of business.

6Aug/090

The Absurdity of the “Cadillac Pick-Up”

Posted by Todd

Over thirty years ago (I won't tell you how old I am), my dear old grandfather said to me, "Honey boy, if they ever make a Cadillac Pick'em Up, I'm going to buy me one!"  Knowing full well, of course, that "they ain't ever gonna make one, you know?"

Now, my grandpa (may he rest in peace) was a true maverick.  Not in the new, political sense where one pretends to be different than an incumbent.  But someone who holds an opinion and sticks with it come hell or high water, if you know what I mean.  A rebel who smoked like a chimney, swore like a sailor, but loved like a saint.  Yesteryear stories encompassed the gamut between being on board ship in the Big War and participating in dancing contests with his betrothed, picking hops and working construction.  So I ask you, why did he think it was so absurd to conceive of a Cadillac Pick-Up?  We used to chuckle about the concept quite regularly while we harvested wood for the winter stove.

If it's true that the deceased actually roll over in their graves when something outrageous happens, grandpa is doing somersaults presently because of the adjacent picture.  Here's your Cadillac Pick-up, Grampa:

The absurd Cadillac Pickem-Up

The absurd Cadillac Pick'em-Up

I wish like crazy that GM could be like other businesses, and disappear when they make stupid business decisions!  Cadillac doesn't mean "pick-up truck."  It doesn't mean "luxury."  It means "big, comfortable, roomy, luxurious car."  Duh and good riddance, GM.  I'm ready for an American car company that gets it.  Quality, innovation and target marketing.

Filed under: Business No Comments
15Oct/080

Positioning, Branding and the Demise of the American Automobile

Posted by Todd

As I drove to work this morning, I saw a black Pontiac Solstice on the highway. Nice car! The convertible top was up due to the temperature here in Denver this morning. Then directly in front of it, I saw a Lincoln LT pickup truck, which got me to thinking about the demise of the American automobile manufacturers. First of all, I thought, "Duh!" My grandfather said many times that he was waiting for the day when they'd make a Cadillac pickup. Too bad he wasn't around to see it. But my point is that he only said it because it was completely ridiculous. Caddilac and pickup don't mix. Cadillac means "big, luxury car."

So what's the difference between Cadillac, Pontiac, Oldsmobile, Chevrolet, and GMC? What are the differentiating factors in deciding to buy a Lincoln, Mazda, or Jaguar over a Ford? Or for that matter, why would you buy a Passat over an Audi A4 (or visa versa)? And who ever thought Porsche meant "high performance SUV"????! Now we know why Porsche profits have been suffering over the last few years. And if the Cayanne has improved them, it's short lived.

Back to that Solstice... Pontiac's tag line has been in recent years, "We build excitement." Cool. I say go with it! And that Solstice looked pretty exciting. I see that on their website, they've chosen, "Pontiac is car." But they also build SUVs. Hmm... something to think about.

Pretty Exciting Looking... The Pontiac Solstice

Pretty Exciting Looking... The Pontiac Solstice

The foreign auto makers have done significantly better in branding and positioning, me thinks. While Toyota does build cars, trucks and SUVs (which, IMHO is a mistake to brand them the same), they have somehow managed to hold the position of "dependable," "long lasting" or "quality" vehicles. So, now people are willing to pay a premium price for their foreign-made automobile in hopes of getting more "value" out of it in the long run.

American auto makers wake up! Stop creating the cross-over confusion, utilize our American enginuity and resourcefulness to build a better product, and differentiate your brands! Long live the Solstice!

Filed under: Business No Comments
21Jul/080

Improving Business from the “Bottom” Up

Posted by Todd

OK, I'm chapped. Both literally and figuratively. I'm continuously amused at how businesses refuse to take care of their "bottom" line by skimping on toilet paper quality! Let's face it, most facilities management departments mistake 80 grit to mean "higher quality" or something... I think my current company went "all out" for its employees and ponied up for only 100 grit and I've certainly worked at places were 60 grit was the norm. But c'mon! Do they think if they provide "real" TP that we'll stock up and take some home? Maybe it's to discourage rest room breaks. Or is it just a money decision--buying the cheapest thing that could possibly work?

Hmm... what are the financial ramifications of all employees running around with a constant rash? I wager there would be less distraction, higher satisfaction levels, longer hours worked, and increased loyalty just from a simple toilet paper upgrade.

What do you think?

Filed under: Business No Comments