BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Add Spelling and Grammar Checking to Any Online Application for Free

by Jonathan Allen on Jun 27, 2011 |

After the Deadline is a free REST based service that provides Spelling, Style, and Grammar checking support to any application that has Internet access. For personal use developers may use the free online server hosted by After the Deadline. Commercial users need to host their own server, the software for which is being offered under the GNU General Public License.

After the Deadline currently offers plugins for Firefox, Google Chrome, WordPress, and OpenOffice.org. With a couple lines of JavaScript After the Deadline’s spelling and grammar checker can be applied to all the textarea tags on a webpage.

Currently there is no support for clients written in .NET or Java so developers for these platforms will have to build their own UI. Arik Poznanski has created a basic C# wrapper around the REST calls, which he then used to build a Windows Live Writer plugin that does just that. Miguel Ventura has created a wrapper for Python and Michael Sepcot for Ruby.

Even when using raw REST calls the API is very easy to use. Simply pass in an application ID and the block of text to be checked and it returns a list of errors with suggestions. A second call can be made to get an explanation for the error.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

call it HTTP API not REST API by Gaetano Miranda

I am no REST expert, but i don't think this API qualifies as RESTful. Why not just call it HTTP API? At least then we know what we're getting, and there is nothing wrong with having an HTTP API.

Re: call it HTTP API not REST API by Jonathan Allen

REST was never RESTful. In virtually any API you are going to need have a mixture of documents and actions, so the theoretical basis of REST was never really put into practice. The technological underpinnings, namely the direct use of HTTP without an abstraction layer, thus became the working definition of REST.

Re: call it HTTP API not REST API by john zabroski

Jonathan,

Please read up on REST.

REST was never RESTful?


REST is an architectural style that was codified to describe what practitioners were doing successfully. To say "the theoretical basis of REST was never really put into practice" is wrong, wrong, wrong. Especially this:


In virtually any API you are going to need have a mixture of documents and actions


This sounds like Gartner Research Group writer Nick Gall, who exhibited a similar misunderstanding. Nothing requires a document to contain control information, and furthermore, (1) nothing requires a document to be stateless, (2) nothing requires a document returned by a request (URL) to be recursively negotiated by connections, (3) nothing requires a document's physical location from being abstracted away behind an opaque identifier (URL).

What is more important than REST itself, if you are indeed trying to find something general to note about why REST was successful, is this:

Atomic processes are easy to re-arrange to solve new problems. Encapsulating each process as a URL, and passing the state of any process back to the client with control information on what other atomic processes can be composed with the document's state, is a fundamental idea in all business systems. It also comes up frequently in real-time engineering. Furthermore, since REST allows hidden state (each user might get a different perspective on the same resource), the control information is highly customized according to what the user is actually allowed to do with the information in the document.

How common is this idea? Well, it underpins building software with Finite State Machines, since transitions are atomic. Many people who explain REST explain it in terms of state machines, including Roy Fielding (ergo, his acronym HATEOAS - Hypermedia As The Engine of Application State).

Again, "mixture of documents and actions" is an over-simplification similar to the ones made by Nick Gall.

The technological underpinnings, namely the direct use of HTTP without an abstraction layer, thus became the working definition of REST.


No, it did not. It became the working definition for marketing teams and things like IBM's WebSphere technologies. Cultural outsiders who don't understand a word should not dictate its meaning. As Whitehead said, "Civilization advances by extending the number of important operations which we can perform without thinking about them." What did Whitehead mean? He meant that first you internalize a concept, like all the principles behind REST, and then you give a name ("REST") so that you can refer to that internalized concept.

Many people, however, appear to have misunderstood Whitehead, or simply try to do the opposite of Whitehead's observation. They try to create an idea out of thin air, naming it, and then defining what it means. That's a BIG mistake.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT