[FEEDBACK] Clarify with DRF

[simkimsia]

I am curious to know so wants to clarify

in https://phalt.github.io/django-api-domains/plugins/#django-rest-framework

you wrote

When using DRF, we can organise the logic in a domain this way:

urls.py - Router and URL configuration. apis.py - DRF view functions or view classes. serializers.py - Serialization for models.

and

https://phalt.github.io/django-api-domains/files (let's call this Files section)

you have a

• models.py
• apis.py
• interfaces.py
• services.py

Plus you have this helpful diagram https://phalt.github.io/django-api-domains/styleguide/#visualisation

Can you help me to understand how the files work with DRF situation? Perhaps another diagram?

Because I cannot visualize how to use DRF on top of what you recommend under Files

Another related question is

DO you recommend the use of GenericAPIView or APIView classes in DRF for the apis.py?

Do you mind giving a visual idea of how two different domains both using DRF would interact with one another similar to https://phalt.github.io/django-api-domains/examples/ ?

What if they are different apps of the same Django project?

[phalt]

So many questions!

Let me tick off a few of the easy ones:

• I almost always use APIView. This is a personal preference, because I like the get/post/put/delete methods on the class, I find the retrieve/update/??/?? paradigm on viewsets hard to remember (I don't actually remember them) and it is jarring for new users. APIView is really simple and works.

• If your django app is providing an API with DRF, then you just use the existing file format as I recommended, but place particular DRF logic in the files I recommened above (so add a urls.py to your domain to handle URLs, for example).

• If you have two Domains in a single Django project, then why are you using DRF to talk between the two? Just use internal software APIs.

[simkimsia]

So to summarize and clarify for my own understanding

• models.py
• apis.py (APIView here)
• interfaces.py
• services.py
• urls.py - Router and URL configuration
• serializers.py - Serialization for models

Correct?

What abt custom methods/actions? Such as change an object from status draft to published with a API like posts/{pk}/publish using PUT or PATCH for example

[phalt]

Custom methods: services.py.

So the apis.py would handle the APIView class, and dispatch actions to the services.py layer for the domain actions. For example, a POST to an APIView could create an order and send an email, so you would wrap the order creation and email sending actions under the APIView. Make sense?

[simkimsia]

So the apis.py would handle the APIView class, and dispatch actions to the services.py layer for the domain actions.

But the APIView itself would still have the custom endpoint action yes? Using my example of posts/{pk}/publish allowing PUT or PATCH, that means I have a

def publish(...)

in the APIView class yes?

[voyc-jean]

In my experience with experimenting with this styleguide, how you structure your views in apis.py doesn't matter all that much, as long as it includes presentation logic. Personally, I make use of APIView and only use the put/patch/get/update/delete methods. You could simply have something like this:

# apis.py
class PublishPostView(APIView):
    def post(self, request, *args, **kwargs):
        result = PostService.publish(post_uuid=kwargs['pk'])
        return Response(result)

# urls.py
from .apis import PublishPostView
urlpatterns = [
    path(
        'posts/<uuid:pk>/publish',
        PublishPostView.as_view(),
        name='publish_post',
    ),
]

I also make use of serializers in apis.py to validate inbound data and to return serializable data.