[j4mie]

I've been heavily inspired by this styleguide over the years, but I still think it's a bit too complex. A few random thoughts:

  - I think "services" is too much of a loaded term. I prefer "actions", and I always use the function-based style.
  - I hate the naming of "APIs" in this document. They use the term "API" when they mean "endpoint" or "view".
  - "Reuse serializers as little as possible" is the single best piece of advice when using DRF. The inline InputSerializer thing is brilliant.
  - Having each each endpoint only handle a single HTTP verb is brilliant.
  - URLs and views should be separate from all other business logic (models, actions etc).
  - For read endpoints and associated business logic, I'd encourage https://www.django-readers.org/ (disclaimer: I'm the author).

[collyw]

After 20 years in this industry I firmly believe that the code reuse thing is way oversold in universities. It seems to be the reason for so much crappy over engineered monstrosities. YAGNI and KISS are far better things to aim for. Avoid duplicate code, but don't start out aiming for reusable code, when most of the time your requirements won't be especially clear.

[miketery]

> "Reuse serializers as little as possible" is the single best piece of advice when using DRF. The inline InputSerializer thing is brilliant.

Can you expand on this? What is the InputSerializer as opposed to custom rest serializers?

[hbrn]

I think the idea is that instead of thinking "here's the object I'm serializing" you should think "here's the view (endpoint) I'm serializing for".

Contrary to what people usually think, the shape of the serialized object is typically defined by the API endpoint, not by the object itself. Different endpoints can (and will) serve different shapes of the same object.

Even if two endpoints serve the same shape today, they can deviate tomorrow. When this happens, most people are trying to resolve it through DRF inheritance, which is wrong.