Here's a quote: "No more standards, no more precise specifications. Just a vague RESTful
philosophy, prone to endless metaphysical debates, and as many ugly
OK, so my view on this is that REST should be thought of as a 'tool' like UML, where the developer gets as much use out of it as is possible without violating the core principles. I think in one respect it is safer than SOAP. A SOAP WSDL service is a security risk. It's a security risk because the WSDL describes every interface into the system, and if a hacker is able to bypass authentication, they can do a lot of damage. I believe there is safety in obscurity. JSON, unlike XML has no description language (yet), and though REST doesn't require JSON, it's the typical method of packaging data in REST. This means that the consumer has to have a good understanding of the underlying data before making calls. WSDL gives away too much information for miscreants who want to hack. I think REST is precise enough to get the job done. The author goes on to complain about the request method mapping to CRUD. I see the mapping as about the most straight forward and compelling features of REST, with one exception, where I agree with the critique: "You want to use PUT to update your resource? OK, but some Holy
Specifications state that the data input has to be equivalent to the
representation received via a GET. So what do you do with the numerous
read-only parameters returned by GET (creation time, last update time,
server-generated token&)? You omit them and violate the PUT principles?
You include them anyway, and expect an HTTP 409 Conflict if they dont
match server-side values (forcing you to then issue a GET...)? You give
them random values and expect servers to ignore them (the joy of silent
errors)? Pick your poison, REST clearly has no clue what a read-only
attribute it, and this wont be fixed anytime soon. Meanwhile, a GET is
dangerously supposed to return the password (or credit card number)
which was sent in a previous POST/PUT; good luck dealing with such
write-only parameters too. Did I forget to mention that PUT also brings
dangerous race conditions, where several clients will override each
others changes, whereas they just wanted to update different fields?"
PUT is a concern, there's an additional REST request method called PATCH that would alleviate the authors concerns, but a PATCH method may not make it though all firewalls. What we do at W3 Systems is use PUT like a PATCH request. Only the variables that were changed are submitted to the PUT. This eliminates the 'race condition' mentioned in the critique. No, it isn't exactly compliant with REST, but IMHO the REST PUT request is overly restrictive. In fact I can't envision a use case where the restrictive PUT specification would be useful, especially in the web based world where REST lives. We will honor the principles, where they make sense.
Web Services API
The W3 SEA framework uses REST almost exclusively for the HTTP service layer. But there are exceptions. REST isn't always the right tool, and I try to follow my grandfather's advice "Never use a tool for anything other than it's intended purpose."
REST is for persisting state. REST is perfect if you are updating database tables.
But what if you need to tell a robot to move 3 meters northwest? If you told the robot to do that twice using REST POST, then you would be violating the principle of idempotency. An idempotent call, when called more than once, leaves the called system in the same state as if the call were made just once. But two calls after using REST to tell the robot to 3 meters northwest would leave it 6 meters northwest. That's a violation of idempotency. REST is not the right protocol for robots.
Fortunately, there is a protocol that's much more natural for robots called JSON-RPC.
So when the page is for managing persistent state - W3 Systems uses REST, but when the page is for managing robots - W3 Systems uses JSON-RPC.
Unlike REST, JSON-RPC is HTTP REQUEST_METHOD agnostic. W3 Systems will use POST exclusively for JSON-RPC calls.
So, once a company has a web-based business system, what about the 'External' website?
The external website should to be an extension of the web-based system. Whatever business a company does, they ought to be concerned about prospects, leads and customer retention in order to continue to do business. The whole idea of a company website is to drive those leads and prospects into the 'sales funnel', and to provide customers with a communication channel back to the business.
Consider the typical 'Contact Us' page. The Contact Us page 'typically' sends email to a particular sales person or group. There are two major problems with that approach.
Email can fail, or you could miss it (most folks are deluged with emails nowadays.)
There is no tie in to your business system. Your business system ought to have contacts, and some of those contacts ought to have the types lead or prospect. This is accomplished in our new system through the "Human Relations" module.
The contact us page should create a contact in your business system, which would then create a work-flow item for sales to contact the new lead. This way the person trying to contact you goes directly into the sales funnel. Or it may be that a customer has a question, or worse, a complaint. The "Human Relations" system will correlate request to the customer, and will create an actionable item that will go into the work-flow for the responsible customer relations person to handle. This will lead to a much more satisfactory result than a sent email.
For businesses that are happy with their existing site, W3 Systems has a REST service to allow the contact form to push the form request information into the "Human Relations" system.
The cellphone is now a ubiquitous feature of daily life. W3 Systems messaging system could place a notification on the salesperson or account manager's phone, with a link to the actionable item that was generated from the contact page. That way, the salesperson or account manager will know immediately that something needs to be done.
Security is the paramount concern of a web based service offering. The new software stack is being written with a security first imperative. Strong passwords, digital hashes, and email based resets will be used throughout on the new systems. The new database interfaces only allow access to the database through a 'Statement', where data coming from a client is fully vetted. The strongest encryption for privacy and authentication will be used everywhere.
Having dealt with the different SSL providers, and what they charge, SSL creates a mild barrier of entry for small businesses, especially since Snowden's revelations, and the normalization of the encrypted web.
I'll be recommending this provider to all of my customers.
I'll also try to support this non profit as much as I can.
Please consider donating.
The new website is up, after several years of pointing to a static page on w3sea.us.
(More on w3sea as the new framework becomes ready, but work is under way. w3sea.us will use the new code, not the hybrid code used here on w3sys.com.)
The code currently behind this website is a refresh of older code that began development in the 90's which was once described by another developer as "a riddle wrapped in an enigma wrapped in a mystery." I really can't disagree with that assessment, but the code works well, has very low overhead, and is conducive to the development of business systems. It's a little less mysterious than it was, and bridges the gap to some of the modern features of HTML5 and CSS3.
I'm currently only taking care of existing customers until the new code base is done. When the new code base is done, I'll be developing SaaS packages for several business domains:
Contact Relationship Management (CRM)
Inventory and Sales Management
Shop Floor Management
Code Development Tools
E-Commerce and Auction Management
I'll also be looking for "user experience" (UX) expertise, developers, and partners with domain knowledge in these or other areas W3 Systems might want to grow into.