ENTRIES TAGGED "REST"

What every Java developer needs to know about Java 9

Introducing updated HTTP client support and JSON API integration.

What every Java developer needs to know about Java 9Java 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.

Read more…

Comments: 2

5 PaaS anti-patterns

Common behavior to watch out for when transitioning to a PaaS

Getting Started with OpenShiftToday 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.

Read more…

Comment

The web is eating software

Web technologies have become the default, and are spreading

photo: KF - http://en.wikipedia.org/wiki/User:KF/DetailsA 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.

Read more…

Comments: 2

Implementing hypermedia clients: it’s not rocket science

Not ugly, not complicated

hypermedia

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.

Comment

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?

Read more…

Comments: 2

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:

  1. Give it a public API
  2. Protect any internal communications so they can’t be reverse engineered
  3. Protect any public communications so that they don’t put end users at risk when they leverage third-party devices and services

Read more…

Comments: 5

Tesla Model S REST API Authentication Flaws

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.

Read more…

Comments: 26

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:

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:

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…

Read more…

Comments: 3

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.

Read more…

Comment

Exploring Hypermedia with Mike Amundsen

The Web Can Teach the Enterprise

The Web’s flexibility has helped it to survive and thrive, pushing well beyond the browser-based universe where it first showed its promise. While I’ve spent most of my time working with the HTML/CSS/JavaScript side, the HTTP side of the original HTML+HTTP combination that built the Web is perhaps even more flexible.

I enjoyed talking with Mike Amundsen, Principal API Architect at Layer 7 Technologies, who has spent much of his recent career encouraging enterprise customers to shift toward web architectures. While REST has emerged over the past decade to eclipse SOAP-based “web services”, Amundsen has eagerly promoted the next step beyond the simple CRUD-based model of early REST work: hypermedia.

Our conversation ranged from the history and foundations of REST through the many ways to integrate that work with existing enterprise practice to a glimpse at what the future might hold for frameworks, design, and architecture.

  • REST as enterprise architectures principles applied to hypermedia (at 1:57)
  • Transitioning from RPC-based models to hypermedia, by including additional information in response. (at 3:00)
  • The value of opinionated message formats and eventual integration into opinionated frameworks. (at 5:51)
  • Shifting from shared understandings of object models to messages. (at 8:50)
  • “Enough coupling, but not too much” to allow mixing of technologies. (at 11:15)
  • Human negotiation, HTTP negotiation, and responsive web design (at 14:20)
  • Read more…

Comment