All AJAX files in LWT

Rebuilding LWT’s API, part 1

Hey everyone, for the next release of LWT I have been working on a complete refactor of the AJAX API that will enhance both security and the development for the future versions of LWT!

The Issue

All AJAX files in LWT
A glance at all the different AJAX files composing LWT before unification.

As LWT was growing, so were the AJAX calls and without any control. In the end, LWT as of 2.8.0 harbored a collection of PHP files with different formats and standards, making the API difficult the expand and to understand.

Architecture Design

The first step to tackle the API proliferation was to understand the needs. To do so I had to force in some format standard, and I ended up with a list of all my endpoints:

It features the following interaction:
  * On GET, ``action_type`` can be:
    * ``version``: the API version and release date.
    * ``test_next_word``: next word to test.
    * ``tomorrow_tests_number``: number of tests for the next day.
    * ``phonetic_reading``: phonetic reading of a text.
    * ``theme_path``: theming path for a file.
    * ``texts_statistics``: various words statistics for each text.
    * ``media_paths``: paths of files and folders in the ``/media`` folder.
    * ``example_sentences``: list of sentences containing a word.
    * ``imported_terms``: list of imported terms through terms upload.
    * ``similar_terms``: similar terms to a given term.
    * ``term_translations``: get the list of term translations to edit it's
    annotation.
  * On POST, ``action`` can be:
    * ``reading_position``: ``action_type`` set to ``text`` of ``audio`` change
    the reading position for a text or its audio.
    * ``change_translation``, with values for ``action_type`` set to:
      * ``add``: add a translation for a new word.
      * ``update``: edit the translation of an existing word.
    * ``term_status``, with values for ``action_type`` set to:
      * ``increment``: increment or decrement the status of a term by one unit.
      * ``set``: set the status of a term.
    * For any other value, set ``action_type`` to:
      * ``regexp``: test if the regular expression is correctly recognized
      (no more usage in code base?).
      * ``set_annotation``: change the annotation value for a term.
      * ``save_setting``: save a setting.

On server side, I had moved from a file-by-file approach to a name-by-name query format. Still better, since I can now access all queries from one file, but not perfect. Moreover, all interactions are now in JSON and I now which script is accessing what.

First returns

Even if not finished, the new API had the following impacts:

  • During term test, the music can play fully and the page does not reload.
  • Less dubious content is send, now everything is JSON. The feeds feature were sending raw HTML and JS code, potentially armful for the user.
  • I have a list of the endpoints

Now, the system was good, but I needed something more robust and standard. I opted for the REST standard, easy to implement and well documented. I will describe that in a later post, so stay tuned!


Comments

One response to “Rebuilding LWT’s API, part 1”

  1. […] records, the initial suggestion, formatted with the help of ChatGPT, looked like the following (see part 1 for […]

Leave a Reply

Your email address will not be published. Required fields are marked *