The REST architectural style started as a model of how the Web should work,
particuarly how web applications should work,
in the sense that we had in the early 90s, back in 1993, 94,
we had a pretty good deployed system, the World Wide Web.
We had clients and servers, user agents,
browsers, whatever you want to call them.
And simple servers primarily serving up files and a few database systems.
they're more than a few implementations of the Web protocols,
we wanted to standardize those protocols as part of the W3C and as part of the EITF.
And in general just to resolve some of the disagreements amongst the developers.
At the time, most of the Web was built informally using
a mailing list, primarily, as our coordination mechanism.
We talked all around the world about a new feature, and frequently we would come up
with an idea in one time zone, and someone would implement it in another time zone.
And by the next morning, you'd know what worked and
what didn't work with that feature.
So it was very freeform, very fast.
As the companies got involved, they of course wanted to find ways
to make use of the Web corporately to make it as one of their platforms.
And so they wanted to make it more businessy, and one of the ways to make
things more businessy is to create common standards for
everyone to adhere to rather than adopt things as you go along.
And as one of the developers of a protocol library for
the Web called lib www dash Perl, and that's the last time
I used www in a product name because it's too hard to say,
I was asked to help work on the standards.
Both the URL standard at the time, the HTML standard, and
later on the HTTP standard.
Because I was a graduate student at UC Irvine, and
I had all the freedom in the world, hadn't started working on my dissertation yet,
and but I had finished all my class work.
And that gave me both the freedom and the ability to write for
the Web in addition to the programming that I was still doing.
And it just worked out that being in that position was great, in
that I could have a hand at making the Web
better because at the time it had grown out in every direction at once.
But at the same time I was faced with the dilemma of,
I have many competing interests
working towards making the Web what they think is a better place
and how do I differentiate between the ones that are actually better for
the Web and the ones that are back to some older version of an architecture
or an architecture that just doesn't make any sense at all on the Internet.
And so I came up with something called ACP object model.
At the time, object models were the thing.
So that's why I called it an object model,
even though it had nothing to do with objects.
And the team that was working on the specification,
mostly myself and Henrik Frystyk Nielsen
at the W3C, we were asked to write the HTTP standard.
And this was my model of describing to each other, basically,
how a particular change to the standard would affect the resulting Web.
Because the Web itself is really a network of standards.
And I used that throughout the years just as basically a thought description.
If someone would offer a feature or
describe something that they thought was wrong with the Web,
I would use the model as sort of an analogy
or a proof point to show what it is about HTTP that works at that model,
and what it is that the new feature might hurt or might help.
And that allowed me some intellectual leverage, in many ways,
to effect how the HTTP standard worked.
It wasn't until many years later after I had done the literature search for
software architecture, that I figured out the right words to use to describe it.
I saw a paper by Dewayne Perry and Alex Wolf,
in the software engineering, one of the software engineering papers,
buried in one of the ACM SIGSOFT proceedings,
which aren't distributed very far beyond your school library and things like that.
But I found this paper, and it was the only software
architecture paper that described architecture in terms of
both the components and connectors of typical architecture diagrams,
but also the data that's processed through the system.
And my realization is that all these architecture papers which I had read.
which didn't make any sense to me
because they were all talking about the blueprints of an architecture.
And this paper was talking about the actual runtime architecture.
The actual behavior of the system, and that's what I was building.
>> It sounds like you were flowing between a very practical and pragmatic world
and this kind of theoretical world, and just flowing gently back and forth for
some period of time and like picking up on both sides.
One of the great benefits I had at UCI was the all the freedom to
pursue these different areas.
I was actually working in a team
doing research on global software engineering environments.
So I was trying to use the Web as a platform for
software engineering, essentially what GitHub is today.
That was my research project,
and as part of that, I could do all of this other work related to it.
One of the nice things about general research funding at the time.
>> So at some point you had to sort of, like, take a breath and
finish your thesis.
>> Yeah, I came from an academic background,
my father's a professor of geography and urban economics.
And so I always wanted to complete the PhD.
It was never a question of running off and joining a startup
even though my startup friends were becoming millionaires left and right.
There was always that desire to finish the PhD.
>> Was it easy to write, did it come naturally at that point would you,
I mean, was the idea fully in your mind at that point?
>> Oh, yeah.
The idea was not only fully my mind but almost past it at that point,
because I finished HTTP, finished the HTTP standard in 1997.
And it wasn't until I had done the work,
that actually a colleague of mine, Larry Micinter came and
was talking to me about a related subject and I was telling him about how,
I've done all this work, I don't know what to do for my dissertation.
And he just looked at me and said well, you're the only one who can describe HTTP,
why it's there, and what it's there for. Why don't you just do that?
And, so that gave me the impetus to actually say, well, I can do this.
I can describe what I all ready did, I can actually describe it.
But then, the question was I been just fooling around in that
that wasn't my academic work.
My academic work was over here and my practical work was on the Web and
I hadn't really mixed the two other than general knowledge.
And for me,
going back and trying to find the real knowledge framework for
architectural styles was my way of fitting it all together.
>> It's funny because when I was a graduate student,
one of the main motivators that the professors would have.
they would very seriously look at us. was don't worry about what you put in your
dissertation. Nobody is going to read it anyways.
I might, because I'm on your committee, but don't worry about it because no one
outside your committee is ever going to read this thing.
Just get it done and go on.
It's just not my style to do that kind of writing.
So I consider it my first book, my only book really.
And for me, writing is very difficult, in the sense that I
spend a lot of time thinking about each sentence, each paragraph.
I'm not the kind of person who writes down a quick rough draft and
then goes through and edits it again.
I tend to edit sentence by paragraph and
add a paragraph then delete two paragraphs, and then go back.
That kind of thing.
So it's gratifying that people like to read a dissertation.
Part of the, it's certainly an accessible piece of work.
It's not full of equations.
There's one equation The equation is there just to have an equation, by the way.
It's not actually necessary, but it's nice to have one.
>> It's rare that academic research has a profound impact, and
honestly the freedom you've had is what everyone should have.
>> Exactly, the freedom gave me the ability to do technology transfer
beyond their wildest imagination, which is great.
What's hilarious from my standpoint is I was just having fun.
I was trying to do my good deed for the universe kind of thing,
and it was all for free, basically.
But it was, for me, fun.
Enjoyable people, wonderful conversations, learned an incredible amount.
Roy Thomas Fielding (born 1965) is an American computer scientist, one of the principal authors of the HTTP specification and the originator of the Representational State Transfer (REST) architectural style. He is an authority on computer network architecture, and co-founder of the Apache HTTP Server project.
Fielding works as a Senior Principal Scientist at Adobe Systems in San Jose, California.
In 1965, Fielding was born in Laguna Beach, California. He describes himself as "part Maori, Kiwi, Yank, Irish, Scottish, British, and California beach bum".
In 1999, Fielding was named to the MITTechnology ReviewTR100 as one of the top 100 innovators in the world under the age of 35.
In 2000, Fielding was granted his doctorate by the University of California, Irvine.
Architectural Styles and the Design of Network-based Software Architectures, Fielding's doctoral dissertation, describes Representational State Transfer (REST) as a key architectural principle of the World Wide Web, and received a large amount of attention. People now frequently hold up REST as an approach to developing web services, as an alternative to other distributed-computing specifications such as SOAP. Fielding has also been heavily involved in the development of HTML and Uniform Resource Identifiers. Fielding was a co-founder of the Apache HTTP Server project and was a member of the interim OpenSolaris Boards until he resigned from the community in 2008. He was the chair of the Apache Software Foundation for its first three years and was a member of its board of directors until May 2014.
Between 2001 and 2006, Fielding worked on Waka, an application protocol intended as "a binary, token-based replacement for HTTP". It was "designed to match the efficiency of the REST architectural style".
- ^"Roy T. Fielding's personal Web site". 2012-11-19. Retrieved 2013-03-04.
- ^"Roy Fielding's publications in Google Scholar". Retrieved 2013-03-04.
- ^"Roy T. Fielding". LinkedIn. Retrieved 2017-08-28.
- ^"Roy T. Fielding: Life story". University of California, Irvine.
- ^Roy T. Fielding (2011-07-27). "Re: OpenOffice.org branding". www-legal-discuss.
- ^Roy T. Fielding (1999-07-02). "Re: Kiwi Fruit". FoRK mailing list.
- ^"1999 Young Innovators Under 35". Technology Review. 1999. Retrieved 2013-03-04.
- ^ abFielding, R. T.; Taylor, R. N. (2000). "Principled design of the modern Web architecture": 407–416. doi:10.1145/337180.337228.
- ^Mockus, A.; Fielding, R. T.; Herbsleb, J. (2000). "A case study of open source software development". Proceedings of the 22nd international conference on Software engineering - ICSE '00. pp. 263–272. doi:10.1145/337180.337209. ISBN 1581132069.
- ^Mockus, A.; Fielding, R. T.; Herbsleb, J. D. (2002). "Two case studies of open source software development: Apache and Mozilla". ACM Transactions on Software Engineering and Methodology. 11 (3): 309–346. doi:10.1145/567793.567795.
- ^Roy T. Fielding (2008-02-14). "Sun's Responses to the OpenSolaris Trademark Questions". ogb-discuss.
- ^"Apache Software Foundation Board of Directors Meeting Minutes". 2014-05-21. Retrieved 2014-07-08.
- ^"A conversation with Roy Fielding about HTTP, REST, WebDAV, JSR 170, and Waka". jonudell.net. 2006-08-25.
- ^Roy T. Fielding, Ph.D. (2002-11-19). "waka: A replacement for HTTP"(PPT).
- ^Fielding, Roy T. (2012). "The Waka Protocol"(PDF). IETF.org. Retrieved 2017-03-23.