An Interview With REST Author Brian Sletten
An Interview With REST Author Brian Sletten
We released an update to the DZone Refcard REST: Foundations of RESTful Architecture by Brian Sletten--who we recently spoke to for more detail about the card.
Join the DZone community and get the full member experience.Join For Free
This week we released an update to the DZone Refcard REST: Foundations of RESTful Architecture by Brian Sletten. We spoke with Brian in order to ask him a little more about his background and find out some of his personal thoughts on utilizing RESTful Architecture.
DZone: Tell us a little about your professional background and how it contributed to your writing of the REST Refcard. When did you first recognize the value of RESTful architecture, and why did you decide to pick it up?
Brian Sletten: I have had the fortune to have a wide, varied and fun background professionally. Much of my early career was in the 3D graphics and user interface space. I worked on the first Whole Earth simulation and visualization environment (think Google Earth, but in 1994). I helped design and build an Internet distributed computing platform at a company called Parabon in 1999-2001. They have taken that platform into some really wild new directions recently including DNA Phenotyping to help law enforcement on cold cases and even to shame litterers in Hong Kong! (http://www.wired.com/2015/05/creepy-ads-use-litterbugs-dna-shame-publicly/) I’ve also helped organizations deal with more mundane but crucial activities such as protecting credit card information, incremental architectural evolution, document processing for NLP and entity extraction as well as API design, development and deployment.
Throughout all of this, I have had to learn and forget an uncountable amount of technology, and that is only during the course of part of a single career. I was drawn to REST a decade or so ago because I realized we needed technology strategies that embraced this reality. The technical and social change that happens around us requires us to allow people to make their own choices. We will never achieve consensus on which are the best technologies to use. Even if we did, we’d change our mind. Resource-Oriented thinking allows us to make progress in the face of this situation and keep what we’ve produced longer by decoupling clients and servers.
DZone: What are some of the most common problems you see developers face when trying to utilize REST?
Brian: The biggest issue with developers doing REST is their bias toward code and implementation rather than the design of the API. Tools that seem convenient as a means of producing REST APIs in a particular language often do so at the expense of the design. Serializing Java objects as XML or JSON doesn’t give you an API and is probably going to tie your clients more closely to your implementation than is good for them. Refactoring the objects will refactor the serialization and break their interfaces. This is exactly opposite of what we are attempting. To be truly successful in the long-term, these APIs should be designed independently of the implementation. This doesn’t always yield the highest performance or most concise interface, but we are trading off a little bit of that for stability and evolvability.
DZone: Tell us about an interesting project you are working on now.
Brian: I’m working with some clients in the space of machine-processable, Web-friendly credential management. I’m part of the W3C Community Group on credentials (http://opencreds.org) and we are working to move the ideas forward into an actual standards track initiative. These ideas are powerful and useful across financial, educational, governmental, personal and professional dimensions as a means of easily making verifiable claims about you and your background. Not only will these be safe and privacy-preserving, they will also make developers lives easier. There are a ton of cool Web-related technologies involved. One I am hoping to see get more adoption as it is finalized is an HTTP Signature specification that serves the dual role of validating the integrity of HTTP messages as well as identifying the agent via digital signatures.
DZone: Why is this Refcard a must-have for developers?
Brian: The Refcard format is a useful way to distill a lot of crucial information in a short form. Without the freedom to blather on for pages on a topic, you have to focus on what is most important. As such, this is an efficient and easy-to-consult medium to learn and revisit the key ideas, reference material (such as the response codes) and pointers to related tools and media. That’s true of all of the refcards, not just this one.
DZone: Are there other REST resources (that aren’t in the card) you would recommend to readers looking to learn more?
Brian: Anyone interested in these ideas should absolutely consider coming to RestFest this fall (http://restfest.org) in Greenville, SC. It’s a fantastic, fun unconference where everyone presents and you eat really, really well. Ben (http://twitter.com/bigbluehat) and Mike (http://twitter.com/mamund) and the others have created something special. I’m psyched about going back.
DZone: Is there anything else you would like to add?
Brian: Only that I encourage people to remember that choosing to pursue REST isn’t an endpoint. It opens you open to being able to think about larger data integration strategies with resource-oriented technologies like RDF, SPARQL (and it’s protocol), Linked Data, etc.
Opinions expressed by DZone contributors are their own.