Alex's Notes

CM3035 Topic 05: CRUD and REST part 2

Main Info

Description

More REST API development: AJAX Frontends.

Key Reading

The textbook reading is worthless.

Lecture Summaries

5.1 AJAX and SPAs

AJAX stands for Asynchronous JavaScript and XML - it’s a concept for building dynamic web applications.

We use the server only as a means of sending data to the UI. Nowadays JSON is the main interchange serialization rather than XML.

The paradigm introduces the following changes:

Conventional ServerAJAX Design
User Agents request completed HTMLUser Agents request data (JSON or XML)
Application consists of many pagesApplication is one, or a few, pages that self update
HTML page construction is on the serverPage construction is on the client
User interaction and data concerns in the server codeUI logic in the client, data concerns on the server

Most of the lectures walk through refactoring the same frontend to be a SPA. It uses the old API, not fetch, so is not that helpful.

Midterm Webinar Summary

Three goals for the midterm:

  1. experience building a web service to a brief.

  2. can you take a data set, normalize it, and design a database

  3. can you build a REST API against the db design.

It’s a logic puzzle, not about understanding the biological data in a deep way.

The most important bit in the instructions is the summary of the database you’re building.

Organisms have many Proteins - so we’re looking at a one to many relationship here.

Organisms have a Genus and Species name - this is one to one, so could be an attribute in the Organism table or a separate taxonomy table if you wish.

Proteins have many domains - so a protein table could be in a one to many table with a domains table.

Looking at the source data:

the first csv file is protein sequences, it has 2 columns, an ID and a sequence. We can use the id to link to the main data set.

The main data set has a protein id column for joining. There are 3 columns about the organism (taxa id, clade id, scientific name).

There are 4 columns about the domain (which could be another table).

There’s one last table with an id of the domain (for joining with the main table) and a description.

So you’re looking at 3 table, Organism, Protein, Domain potentially. But up you to review normalization principles.

In the API spec, note that the ‘id’ in the json response is not actually in the dataset, it’s the auto-generated Django ids.

Looking at the requirements now:

b) correct use of form, validators and serialization - up to you how to use form validation, django serializers etc. You choose and explain in the report.

For the midterm, it’s just the REST API, there is no frontend needed.

The report is really important - you need to explain why you chose your database design, why you used serializers or not, which bits of DRF are you using, why?

Don’t just repeat the textbook.

Hook up the Django admin panel.

You do need a script to import the data. But import the data before submission.

Ideally integrate the script into the Django app so you can do python manage.py load_data - better marks for that kind of integration rather than a separate script.

Another common area to lose marks is tests. Test every endpoint, but also test eg the import data script.

If you set up admin remember to give them the credentials.

Above and beyond points for referencing literature (even industry blogs) around best practices, including git workflow, testing etc.

For the landing page consider adding links to the REST endpoints, so that the markers don’t have to access them themselves.