04029437
m2.26
Senses are related to one or more lemmas, senses are related to zero or more senses. The
ER
(Entity-Relationship) diagram shown below describes these relationships in more
detail.
Based on this we could assume a REST system would be suitable. However, there are a
couple of issues with REST. REST is stateless, each call to the server is a separate
unconnected event, this means we cannot use past events to shape the response data.
Complex data processing is completed client-side because we cannot execute remote
code.
In the uses-cases we explained that we do not need to use a stateful approach. We did
however indicate that there is state data, i.e. data which, irrespective of the resource,
significantly modifies the response data. For example, when we retrieve alternative
terms for a lemma of an unknown sense, knowledge of other terms in the query and
their senses may prove a valuable asset.
REST systems indicate that we are accessing specific resources and presenting them
using different representations. Integral to REST is the separation of the four CRUD
features, this is represented by the use of the HTTP methods
GET
,
POST
,
PUT
and
DELETE
.
This makes the retrieval of data, achieved via
GET
, limited to the URIs by which
resources can be identified. This restricts the complexity of data we can pass when
retrieving data.
JSON-RPC gives us more flexibility than REST and because we aren't restricted by the
concept of resources, we can perform a great deal of server-side processing, completely
abstracting it form the client. JSON-RPC 1.0 only accepts
POST
requests and although
POST
requests aren't suitable for all procedure calls, we must remember that support for
the
GET
method will be added to the JSON-RPC specification in the future.
Using solely
POST
could provide a major benefit. Earlier we mentioned the use of
multiple formats on one Web-Service. If the server always used the
POST
request it
would be possible to detect the encoding of the incoming message by the MIME type,
for example
application/json
. This could be used to determine the format of the
response data.
JSON-RPC offers error handling and sequencing, both of which are encapsulated in the
wrapper. A standard error handling mechanism ensures that all developers are capable
of handling errors in a suitable way. It also means third-party libraries can easily
understand the response before passing it to a local handler.
It is likely our client will make a large number of requests is a short space of time. If
responses are not returned in sequence, JSON-RPC sequencing ensures we can easily
identify which request each response correlates to.
JSON-RPC provides the most comprehensive solution and it does not over complicate
the communication process. Lack of support for
GET
requests is likely to be remedied in
the near future. This is therefore the most suitable mythology for our system.
5.6 Suggestion Data Structure
Ultimately our format is restricted by the encoding, however, since JSON does not
define any overly complex data types or structures, we can keep the data structure
