To help make the selection process easier the table below describes the three
methodologies we have just described in relation to features that are important for our
Familiar to existing developers
Third party libraries available
Written for JSON
* There is no specification for REST error handling, but we can build this into the schema
REST is very much a conceptual methodology, although it is not designed specifically with
JSON in mind, JSON can be transmitted using REST.
§ The HTTP request type is related to the REST operation, for example to retrieve data we use
Full Support for
is included in the draft specification of JSON-RPC 1.1.
Proprietary methodologies fall into the same trap as those that proprietary encoding fall
into. Lack of support from third-parties and lack of knowledge combined with
unwillingness to learn very specific skills, makes proprietary best suited to in house and
We need our system to be as open as possible if it is to provide a viable mechanism to
serve search suggestions. Simply publishing a schema does not make it open, only once
developers are comfortable with a new technology and the new technology is safe and
reliable will it be accepted as an open solution.
Standard interfaces are generic by nature. If we use a standard interface, the interface
must be customisable and extensible. If it is not, we risk creating an interface that is too
generic and will put unnecessary strain on the server and or client. Using a standardised
approach brings a number of benefits; most prominent are:
Easy for other developers to learn
Existing libraries and resources
Expertise is available
The REST and JSON-RPC methodologies both provide standard customisable and
extensible solutions. Hence a proprietary methodology is not really suitable. For our
project a proprietary method would only really be useful if the other offerings were
In its most simplistic form, our data can be thought of as two entities, lemmas and
senses. Lemmas have zero or more senses, lemmas are related to zero or more lemmas.