REST is in the eye of the beholder
July 26, 2016
The first time I came across the term REST must have been around 2005 or 2006 via Flickr, which was back then in many ways a pioneer in terms of how web applications should be built and designed.
REST, at the time, was a breath of fresh air and it seemed very sane in a world where SOAP and XML-RPC were dominant. I can look at a webservice straight from my browser? Wow. Returning simple XML documents instead of using XML as the transport made a lot of sense.
I’m not really sure if Flickr was the first to use the term REST for that type of service, but in my memory it played a fairly big part in popularizing it.
But it’s not REST
It took me some time, but I slowly started realizing that this was actually not a REST service. Not before I deployed a similar API and stamped it “REST” though.
As it turns out, REST is more than “simple documents”. We learn we also
need to use correct HTTP Verbs such as
Over time the definition for me and many people around me evolves, which eventually brought me to a point where I found out what the original definition was all along.
REST stands for “Representational State Transfer” and was invented by Roy Fielding, one of the authors of HTTP/1.1 and described in his dissertation.
REST has a specific meaning and a ‘best practice way’ to implement it when using HTTP, and Flickr and pretty much anyone else joining the REST hype is getting it wrong, much to Fieldings annoyance (2008).
And he’s not alone. What follows is a storm of articles, conference talks, tweets and even some books describing what REST is and describing in what way many people got it wrong.
So what is REST?
Well, over time we’ve gotten better at describing what REST is. We now have the term HATEOAS, which rolls off the tongue amazingly. A service cannot call itself REST unless it’s also HATEOAS.
We also now have the Richardson Maturity Model, which is a bit like the seven stages of grief, but for REST. Basically, you cannot call your service REST unless you’re on Level 3 of the Maturity Model.
I’d highly recommend reading the fowler article, because it’s one of the best overviews. The maturity model maps out my personal learning curve as well.
But here’s the issue
I believe that “REST” is widely believed to be the “right” way to implement web services. The term is also almost universally used to describe services that actually are not hypermedia-driven a.k.a. not comformant with Level 3 of the Maturity Model.
Almost everyone gets it wrong.
But the thing that they got wrong is not necessarily the API they’ve built. It might be good (enough) and appropriate for what they are trying to accomplish. The thing they get wrong is that according to purists, they should not be calling their service REST, because it aint.
I think doing HATEAOS correctly is overkill for most people. Modelling it correctly is actually quite hard. It’s also prone to a lot of round trips.
A comment from Fielding:
REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release. There are more than a few software methodologies that portray any long-term thinking as wrong-headed, ivory tower design (which it can be if it isn’t motivated by real requirements).
The reality is that a lot of us actually do see the value of achieving short-term goals, preferring ease-of-use over correctness. We’re not building an API for the library of congress. Having lots of people use an API is probably more important than that API being relevant for multiple decades.
What I’m really suggesting is that ‘correct REST’ is wrong for most people, but this leaves us with a major problem.
There’s a massive body of work that calls itself REST but is not quite REST. Any developer tasked with building a service might therefore come to the conclusion “REST” is a good thing.
Now, this developer might have questions about the design of their new REST service on Stack Overflow and find out that there’s a wild range of different answers based on the answerer’s definition of REST.
A common one might be: what is a good way to design my REST url structure? A ‘correct’ answer might be, the url structure doesn’t matter as all URLS must be discovered.
Correct? Yes! Helpful? No!
Developers might fight their way through it and still end up with enough resources and answers to develop their ‘not quite REST’-service.
Or alternatively, the developer might go all the way down the rabbit hole, and come to the conclusion:
- REST is popular choice for good API’s.
- Therefore REST is good.
- REST must be hypermedia-driven.
- Therefore good API’s must be hypermedia-driven.
I’ve seen many people fall for this logic trap, not realizing that it’s based on a false assumption. REST is not popular. Something that’s not quite REST is popular and everybody just calls it that.
We don’t have a good popular term to describe simple web API’s though, which makes it difficult to research. Most REST books and presentations you’ll find tend to be about ‘correct REST’ not ‘popular REST’, but most services are ‘popular REST’ not ‘correct REST’.
I think coming up with a new term and popularizing it is going to be very difficult though, so I propose that we let the programming lingo evolve the same way words’ definitions in languages do. “REST” is far and wide used to describe non-hypermedia API’s, so I think it’s safe to say that the term has evolved from it’s original meaning.
Sorry Roy. At least you still have HATEAOS.
Some further reading
Microsoft released a pretty great REST API Guidelines document that’s actually not hypermedia. If you’re looking for a body of work that does try to stick very close to the original definition of REST, take a look at Collection+JSON, which is highly correct and highly impractical.
Nextcloud Is Just An Ordinary Dirty Deal
July 21, 2016
Nextcloud is not moral. Nextcloud is the fruit of an ordinary dirty business deal, rooted in betrayal. ownCloud doesn’t look very good in this sad sorry saga, either.
Back when Frank Karlitschek left ownCloud to launch Nextcloud, he claimed it was a moral decision. But he has never articulated the morality that lay behind that decision. Frank’s number two, Jos Poortvliet, has published many words on this without any specifics, though the quantity and vigor of handwaving is rather impressive. Jos and the other people who left ownCloud to follow Frank promised they would tell The Real Story.
I’m still waiting to hear their version of The Real Story. So far it’s just Real Vapor.
I think their Real Story is the same as mine, and they’re too ashamed to tell it. This is what really happened: Frank made a deal with Spreed behind the backs of his ownCloud partners and founders, then deliberately sabotaged an ownCloud acquisition that was all but finalized. That acquisition would have meant a nice infusion of cash and resources. Killing the acquisition caused ownCloud, Inc. to close its doors and lay off all US employees, including me. It also created difficulties for ownCloud GmbH, but so far they are surviving thanks to a different acquisition deal.
I’m dying to hear how backstabbing your partners, trying to kill a competitor, and costing people their jobs is moral. The tech press completely failed on this story, and have been publishing gushing reviews of how this is so wonderful, and how Nextcloud is all cool because Community and Transparency and Purity and other silly fanboi junk. Get real, friends, the only thing that matters to the Nextcloud crew is money. Only one tech reporter, Barb Darrow at Fortune, did her job and got the real story (see Why Did File Sharing Startup OwnCloud Shut Down?).
Meanwhile, those of us who lost our jobs are still waiting for our final paychecks. I’ve lost count of the excuses and broken promises that oh yes, we will be paid any day now. Sure we will.
The best punch line is Frank offering jobs to former ownCloud employees. Riiight. Fool me once, shame on you. Fool me twice, shame on me. Enjoy your money, former friends, perhaps it will buy you a clear conscience.
New in owncloud 9.1
July 21, 2016
Today is the release of the long awaited ownCloud 9.1 Community Edition. It includes significant improvements for users, administrators and developers.
- Authentication – ownCloud is delivering innovative security features like pluggable authentication and token based authentication sessions. You can now also list all connected devices in your personal user’s page and invalidate sessions if needed. Another significant security improvement is device specific tokens. This allows you to control the access to your ownCloud on even more secure ways. Time-based one-time passwords (TOTP) enable users to automatically increase the security of their accounts by using services like Google Authenticator or the open-source implementation of the TOTP standard.
ownCloud has partnered with PrivacyIDEA, an open source authentication server solution with a lot of experience with authentication, provided by Net Knights GmbH.
- Collabora Online – We’ve teamed up with the developers of Collabora Online and provided a Docker Image for collaborative online document editing. We encourage our users to use the collabora vm which can be also found here. Available formats for editing are DOC, DOCX, PPT, PPTX, XLS, XLSX + ODF.
- Ultimate Scalability – ownCloud’s goal is to get users the files they are looking for quickly and smoothly, and as larger installations are being deployed, ownCloud has collaborated with large ownCloud users, like CERN and Sciebo, to bring the scalability of ownCloud to a new level. To be able to deliver petabytes of data to hundreds of thousands of users, key areas like the storage and sharing functionality of ownCloud have been improved. ownCloud 9.1 can now use multi-bucket object storage as a backend.
- Full Federation – ownCloud 9 brings federation of ownCloud servers to a new level with better performance; resharing a federated share does not create a chain of shares any more, but instead connects the share owner’s server to the reshare recipient.
- Contacts, Calendar and ownCloud Mail – Contacts, Calendar and ownCloud Mail have all received significant updates and improvements. They can be updated conveniently in the ownCloud App Store. For example: Birthdays are now also generated based on shared address books owncloud/core#23510 in your ownCloud Calendar.
With the latest release of ownCloud Community Edition, it is only a matter of weeks before ownCloud 9.1 Enterprise Edition will also be released and available to our customers.
Introducing Improved Project Collaboration with ownCloud Central
July 20, 2016
- In the forum (and to a lesser extend on the user mailinglist and IRC), a lot of regular volunteers have very successfully covered users’ issues in getting up to speed.
- On the mailing lists and on GitHub, sometimes miles high above and in a mostly disjointed community developers have been developing away.
Between the two, there has been a big divide that was unsatisfying. Also neither Forums nor Mailing lists are a good fit for agile communities these days.
So let’s fix this! The forum moderators and sysadmins, have long been wanting to move off our old trusted forum for this reason, and had decided to use Discourse. Now we finally have a new host, courtesy of ownCloud GmbH, to carry a successor.
Please welcome: ownCloud Central!
- A place for newbies and regulars to ask questions
- A place to collect, write and evolve high quality Q&A/tutorials
- A place to get involved in development and discuss new features, before moving them to GitHub for implementation
- A trust system: The higher the trust level, the more rights you get. And, of course, badges for busy beavers
- Much much more: We’ll use it to organize events, spread news, and collect feedback about ownCloud Central itself!
I want to give a big shout out to RealRancor and tflidd, who have done terrific work on migrating the FAQs and vital articles to the new platform. Next, we’ll put the forum into read-only mode and will archive its contents. ownCloud Central will take over. We also migrated all accounts from the old forum. Let’s continue to make ownCloud awesome together!
ownCloud 9.0.4, 8.2.7, 8.1.9, 8.0.14 released
July 19, 2016
A third party component called “Guzzle” is affected by HTTPoxy vulnerability (as filed as CVE-2016-5385 for PHP). This component, which handles http requests on behalf of ownCloud can be tricked into passing inbound requests to a proxy server controlled by a third party. in combination with the ajax cron feature, the third party can potentially see external storage credentials and data. We recommend to use system cron whenever possible, which also significantly improves reliability and experience.
If possible, we recommend an immediate update to 9.0.4, 8.2.7 or 8.1.9 respectively, which each contain a patch for Guzzle. ownCloud 8.0 is shipping an older version of Guzzle and is not affected. However, 8.0.14 fixes a number of other issues and we encourage everyone on older versions of 8.0 to update right away as well.