#95 Refactor api endpoints with according frontend necessities
Closed by davidcarlos. Opened by vbertulucci.
kiskadeemes/kiskadee api-refactor  into  master

Download 95.patch

Overview

  • The existing endpoints now return an specific and little result as json;
  • Implement some other endpoints to ensure that they return only what it needs;
  • Tests implemented to the new endpoints and fix get_analysis_as_json test according the new result from its endpoint.

This is a bad thing to do in my opinion. I don't like the ideia of iterate on the results list, just to get the last analyzed package version. I prefer to do this kind of stuff on the frontend and keep the api the most simple as possible.

The same problem here, iterates on results is not the best solution. Would be better if we add a generator_version and a generator_name field on the Analysis model for example.

2 new commits added

  • Add AnalyzerSchema to serializers
  • Use serializers on package router to format query object

rebased onto 4814f9dde7b96155ba10864893ba80936d7b075a

3 new commits added

  • Add AnalyzerSchema to serializers
  • Change /package router result
  • [API] Refactoring api endpoints for analysis

I believe that its not necessary to add generator_version and generator_name on Analysis model because we can get this attributes from the Analyzer and Analysis relation, using Analysis attribute analyzer_id. If we save this ones on Analysis model, we are going to duplicate some Analyzer attributes on database.

I have solved this using eagerload from sqlalchemy for inner joins and it works fine.

Pull-Request has been closed by davidcarlos

MERGED

Metadata