Add Spelling and Grammar Checking to Any Online Application for Free
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.
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.
call it HTTP API not REST API
Re: call it HTTP API not REST API
Re: call it HTTP API not REST API
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.
Olav Maassen, Liz Keogh & Chris Matts Mar 08, 2014