"REST" entries
Cross-pollinating Web communities
The integration of the Web's diverse communities broadens horizons and technology.
Web projects are integration projects, combining skills from a number of disciplines. Lousy interfaces can obscure brilliant code, and ingeniously engineered back-end systems can still fail when they hit resource limits. “Content” lurks in many guises, requiring support not only from writers and illustrators but from video specialists, game designers, and many more. Marketers have built businesses on the Web, and influence conversations from design to analytics. You don’t have to be a programmer to do great work on the Web. The Web stack is vast.
Web development models include far more than code. Creating great websites and applications demands collaboration among content creators, designers, and programmers. As applications grow larger, supporting them requires adding a cast of people who can help them scale to demand. As projects grow, specialization typically lets people focus on specific aspects of those larger disciplines, supporting networking, databases, template systems, graphics details, and much more.
In some ways, that’s a recipe for fragmentation, and some days the edges are sharp. All of these communities have different priorities, which conflict regularly. Battles over resources sharpen the axes, and memories often linger.
At the same time, though, often even in environments where resources are scarce, different perspectives can reinforce each other or create new possibilities. Sometimes, it’s just because the intersection spaces have been left fallow for a long time, but other times, the combinations themselves create new opportunities. Read more…
What every Java developer needs to know about Java 9
Introducing updated HTTP client support and JSON API integration.
Java 8 may only have been released a few months ago, but Oracle has already announced the first set of features that will be targeted for Java 9. On August 11th, Mark Reinhold, a Chief Architect for Java, made available an initial feature set to subscribers on the jdk9-dev mailing list.
The crop of features are being run under a relatively new process, known as Java Enhancement Proposals (JEP). This process allows new language and VM features to be prototyped and explored without the full weight of the normal Java standardization process, although the expectation is that suitable, successful JEPs would go on to formal standardization. There will, of course, be many other new features that will be introduced in Java 9, but in this post we are going to focus on two major enhancements — and examine how they relate to features added in Java 7 and 8.
5 PaaS anti-patterns
Common behavior to watch out for when transitioning to a PaaS
Today I am going to cover 5 ways developers may be on a Platform as a Service (PaaS) but have not really embraced the new platform effectively. If you have done any of these things below while building your application hosted on a PaaS, like OpenShift, Heroku, or Google App Engine, don’t feel bad:
- PaaS is a relatively new concept in the development world and I think some of these patterns are only recently coming to light
- I have seen veteran developers making these mistakes as they move to the new paradigm
One piece of terminology I will use throughout the article is container. When I am using this word I am referring to the piece of the PaaS that hosts the application and does the work. An application can be composed of multiple containers and the PaaS will probably have a method to add your favorite server-side tech to the container. On OpenShift this is called a gear while on Heroku it is called a dyno.
So without further ado, let’s dig in on some of the code smells in the cloud.
The web is eating software
Web technologies have become the default, and are spreading
A few years ago, venture capitalist Marc Andreessen wrote that “software is eating the world”:
Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.
That may be true, but Andreessen seems to have left out some of his earlier, more Web-centric visions (though perhaps he considers them complete).
Software may be eating the world, but the Web has been “eating software” in a similar sense for as long as the Web has been visible.
On the front end, the browser has grown from being a strange dumb terminal of documents and forms to a full partner. The browser not only provides a window into the world of classic websites, but helps us deal with devices that we can reach over a network. Their interfaces may be invisible or basic on the physical device, but offer much more when accessed through a browser. Web apps, though frequently not as capable as their desktop competition, long ago passed the point where their collaborative possibilities were more valuable than the details they lack.
Implementing hypermedia clients: it’s not rocket science
Not ugly, not complicated
At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Layer 7 Principal API Architect Mike Amundsen demonstrated how to build hypermedia clients, for situations with and without humans in the driver’s seat.
(If you’d like to know more about hypermedia in general, this interview provides more background.)
In his talk, Implementing Hypermedia Clients: It’s Not Rocket Science, Mike explored how hypermedia approaches drive conversation between clients and servers, and the application structures that result from those structures.
- 1:44 – “The Semantic Gap: Hypermedia tells us what we can do, but it doesn’t say why.”
- 6:04 – Hypermedia and application control information – links!
- 8:09 – Control factors – “I accept RSS, can you give me RSS?”
- 10:41 – Foundations of the class scheduling domain example
- 16:30 – “What is a hypermedia client that a human would use?”
- 19:24 – “Faithful Hypermedia Clients (FHCs) pass along whatever the server returns, and lets a human sort it out.”
- 31:20 – “So what’s a Hypermedia for machine client?… Makes choices, not waiting for a human”
- 33:25 – Working with Maze+XML
- 37:10 – The power of generic types
If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.
Web application development is different (and better)
On both front and back end, the Web challenges conventional wisdom
The Web became the most ubiquitous distributed application system because it didn’t have to think of itself as a programming environment. Almost every day I see comments or complaints from programmers (even brilliant programmers) muttering about how many strange and inferior parts they have to deal with, how they’d like to fix a historical accident by ripping out HTML completely and replacing it with Canvas, and how separation of concerns is an inconvenience. Everything should be JavaScript.
(Apologies to Tom Dale, who tweeted a perfect series of counterpoints just as I was writing. He has visions of rebuilding the rendering stack in JavaScript, but those tweets are not unusual opinions.)
The Web is different, and I can see why programmers might have little tolerance for the paths it chose, but this time the programmers are wrong. It’s not that the Web is perfect – it certainly has glitches. It’s not that success means something is better. Many terrible things have found broad audiences, and there are infinite levels to the Worse is Better conversations. And of course, the Web doesn’t solve every programming need. Many problems just don’t fit, and that’s fine.
So why is the Web better?
The Myth of the Private API
The Fundamental Interconnectedness of Things
A little over a week ago, I wrote about how the authentication model for an unpublished Tesla REST API was architecturally flawed because it failed to take basic precautions against the sharing of credentials with third-parties common to most REST-based services these days. Since its publication, the main criticism of the article centered around the fact that the API is neither a published API nor has it been advertised as being meant for third-party consumption.
The adding of value to devices and services with or without the knowledge/permission of their creators is an integral part of the Internet of Things. These days, people expect an API around their devices. They will discover any APIs and add value to the device/service—even if the task requires a little reverse engineering work. A responsible creator of a device or service in today’s world defined by the Internet of Things must therefore do the following things—always:
- Give it a public API
- Protect any internal communications so they can’t be reverse engineered
- Protect any public communications so that they don’t put end users at risk when they leverage third-party devices and services
Tesla Model S REST API Authentication Flaws
[contextly_sidebar id=”fac2d6589aabb899e309cf4413768c10″]As many of you know, APIs matter to me. I have lightbulbs that have APIs. Two months ago, I bought a car that has an API: The Tesla Model S.
For the most part, people use the Tesla REST API via the iPhone and Android mobile apps. The apps enable you to do any of the following:
- Check on the state of battery charge
- Muck with the climate control
- Muck with the panoramic sunroof
- Identify where the hell your car is and what it’s doing
- Honk the horn
- Open the charge port
- Change a variety of car configuration settings
- More stuff of a similar nature
For the purposes of this article, it’s important to note that there’s nothing in the API that (can? should?) result in an accident if someone malicious were to gain access. Having said that, there is enough here to do some economic damage both in terms of excess electrical usage and forcing excess wear on batteries.
The Appeal of the Lift Web Framework
The extreme end of weird (as far as web frameworks go)
Lift is one of the better-known web frameworks for Scala. Version 2.5 has just been released, so it seems like a good time to show features of Lift that I particularly like.
Lift is different from other web frameworks (in fact, I labeled it at the extreme end of weird in the first presentation I gave about it), but people who get into Lift seem to love the approach it takes. It’s productive and enjoyable, which goes well with Scala.
I’ll keep this post short. Just two things:
Transforms
You might be familiar with an MVC approach to the Web, where you have code that forwards to a view, and in that view you maybe use a little bit of mark-up to loop or display values. That’s not how it goes in Lift.
Instead, you start with the view first, and use HTML5 attributes to mark the parts of the view that need transforming. Here’s an example:
<p data-lift="Poems"> The work of <span class="author">someone</span> includes <span class="title">something</span>. </p>
That’s valid HTML5. You can view it in your browser, or edit it in Adobe Fireworks, or whatever tool you want. The only part of it that looks a little strange is the data-lift attribute. What that’s doing is naming a Lift snippet, and a snippet is just a class. It might look like this:
package code.snippet
import net.liftweb.util.Helpers._
class Poems {
def render =
".author *" #> "Philip Larkin" &
".title *" #> "This Be The Verse"
}
What’s going on here? We’re using a nifty DSL in Lift to transform the <p> tag so that it contains the content we want. We’re saying…
Looking Forward, a Leap
Will the Web shift?
Over the last few months, I keep finding new signs that the way we approach web development is about to shift. The parts – which have mostly existed for a while – haven’t completely come together yet, but the next year or two should be exciting.
In 2005, the Web changed without a major new technical push. When Jesse James Garrett wrote “Ajax: A New Approach to Web Applications“, he was describing a combination of techniques that had been around for a while but only combined in the previous few years. At about the same time, JSON, a format that Douglas Crockford had unearthed from existing JavaScript syntax, began its steep ascent. We’ve spent much of the last eight years learning the powers of these new combinations of old things, and celebrating the revitalization of the web ecosystem that they launched.
Today’s shift is a little different: change has been in the air for a while. We don’t exactly have Browser Wars any longer, though there’s still plenty of drama. HTML5 is not only in development, it’s becoming normal rapidly. Some pieces are moving and arriving faster than others, and there is always the challenge of a multi-browser world. There is much much more you can do across browsers today, though, and JavaScript has made it easier to fill the gaps.
Beyond the long-awaited features of HTML5, I see three major factors driving a larger shift:
-
The ever-increasing variety of mobile devices has shattered limits designers imposed on their work.
-
JavaScript practice is maturing, even as the first major additions to the language seem about to arrive.
-
A long slow shift toward hypermedia models (REST and beyond) for application development.
As mobile devices become ordinary, designers are having to give up the last shreds of “the web site must look like this printout”. Dynamic HTML and then Ajax gave sites much more motion and changeability, but usually within a design that was roughly stable. Creating a second stable design for mobile was never a great compromise, but the explosion of mobile devices has forced developers to move toward designs that take much heavier advantage of web-centric styling approaches. Responsive web design is evolving fast.