how to write APIview to access a specific item by using APIViews only

[Rakhee Menon]

CODE:

class FormList(APIView):

def get(self, request, id):

import ipdb;ipdb.set_trace()

item_obj = ItemMaster.objects.get(id=id)

serializer = ItemMasterSerializer(forms,many=False)

return Response(serializer.data, content_type="application/json")

def get(self,request):

forms = ItemMaster.objects.all()

serializer=ItemMasterSerializer(forms,many=True)

return Response(serializer.data, content_type="application/json")

I get this error.django-got-an-unexpected-keyword-argument-id. 

when i try to access a specific item..Please can anyone suggest how to solve this bug using APIViews and not by using viewset  as there is lot of customization in my API.

[Vijay Khemlani]

To retrieve a particular object in your API you should implement it in a method called "retrieve", not "get", if I remember correctly

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8f1a1edf-ed7f-490f-8c29-73aa31531a3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rakhee Menon]

But while using APIView there is no retrieve method.We have only get,post,delete and put methods.

As there is lot of customization in my API i need to use APIViews only... So please tell me how to access specific items using APIViews

[James Schneider]

The issue arises because you are defining the get() method twice with different signatures. The second definition of get() without the id argument is the 'active' definition since it is defined last, and had no idea what to do with the extra 'id' argument.

Python does not support function/method overloading like Java, because of PEP 8 and keep it simple and DRY and everything else about the Python philosophy. It also ultimately names for cleaner and more legible code.

Not sure what you mean by a lot of customization. This code is pretty boiler plate and would be better served by using a generic viewset in DRF, such as ReadOnlyModelViewset:

http://www.django-rest-framework.org/api-guide/viewsets/#readonlymodelviewset

-James

[Rakhee Menon]

Customization in the sense..I have lot of calculations to do so its not possible using viewset.

[James Schneider]

On Sep 5, 2017 11:21 PM, "Rakhee Menon" <menonr...@gmail.com> wrote:

Customization in the sense..I have lot of calculations to do so its not possible using viewset.

Ah, that isn't reflected in the example code you provided. Fair enough.

Custom logic like calculations can be integrated in to any view or viewset. Often times the logic is broken out in to separate standalone functions and called by some simple overrides on the view[set]. 

You can do everything with an APIView if you'd like, but you may be signing up for more work than necessary. If you have your heart set on APIView for whatever reason, you can tweak your code by combining your two get() definitions in to one:

from django.shortcuts import get_object_or_404

class FormList(APIView):

    def get(self, request, id=None):

        if id:

            obj_data = get_object_or_404(ItemMaster, id=id)

            many = False

        else:

            obj_data = ItemMaster.objects.all()

            many = True

        serializer = ItemMasterSerializer(obj_data, many=many)

    return Response(serializer.data, content_type="application/json")

Admittedly I haven't dealt with DRF serializers in a while, but I believe that will work. YMMV.

-James

[James Schneider]

Custom logic like calculations can be integrated in to any view or viewset. Often times the logic is broken out in to separate standalone functions and called by some simple overrides on the view[set]. 

I forgot to mention, you may want to integrate that business logic directly in to your models if the logic will be accessed from more than one view, rather than trying to crowbar in the same operation to multiple views. Model managers work well for logic that is applied across groups of model instances (ie filtering specific instances out, or performing calculations based on a set of criteria against a model type), and methods defined directly on the model should work specifically with that model instance without the need for a crazy view. 

Typically very little business logic is integrated in to the views (which is why so much work has gone in to making them generic, they are often boiler-plate with minute differences such as the template to render or the class of model to query). 

-James

[Rakhee Menon]

Thanks a lot James :-)

[Melvyn Sopacua]

One of the core design issues with DRF is that everything
is based around a queryset. Even if the set is just one item.

Django makes a clear distinction throughout, from model to
view and doesn't combine list and detail views based on the
absence or presence of an identifier.


On Wed, Sep 6, 2017 at 9:06 AM, Rakhee Menon <menonr...@gmail.com> wrote:
>
>
> Thanks a lot James :-)

>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to django-users...@googlegroups.com.

> To post to this group, send email to django...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-users/c13da61b-eebc-49e3-a85a-88482541c1d8%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Melvyn Sopacua

[Xavier Ordoquy]

> Le 6 sept. 2017 à 10:00, Melvyn Sopacua <m.r.s...@gmail.com> a écrit :
>
> One of the core design issues with DRF is that everything
> is based around a queryset. Even if the set is just one item.

This sounds like an easy troll.
A lot of code from DRF is based around queryset because DRF can introspect and deduce a lot from them.
How is DRF supposed to perform filtering on something that we don’t know (aka not based on a Model) ?
Same question for automatic field generation, constraints, pagination and so on.

One thing people need to realize is that:
1. It’s simple to use DRF with non model data, including viewsets - as opposed as what I’ve read on this thread.
2. developer has to write way more code because the framework can *not* guess anything from it
3. A lot of code and documentation covers things based on models because models embedded data description in a structured way while we can’t say much about non model things.

Regards,
Xavier.

> Django makes a clear distinction throughout, from model to
> view and doesn't combine list and detail views based on the
> absence or presence of an identifier.
>
>
> On Wed, Sep 6, 2017 at 9:06 AM, Rakhee Menon <menonr...@gmail.com> wrote:
>>
>>
>> Thanks a lot James :-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users...@googlegroups.com.
>> To post to this group, send email to django...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/c13da61b-eebc-49e3-a85a-88482541c1d8%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Melvyn Sopacua
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Bgw1GUuk3kLZ90w5HX9jxVQQJD%3DnEMRh%3DoozcP-BcQPH74P0w%40mail.gmail.com.

[Rakhee Menon]

Thanks a lot people...I haven't tried writing logics in models.As you have suggested I would like to learn writing business logic in models.So can u provide with any links showing such examples??

[Melvyn Sopacua]

On Wed, Sep 6, 2017 at 10:19 AM, Xavier Ordoquy <xord...@linovia.com> wrote:
>
>> Le 6 sept. 2017 à 10:00, Melvyn Sopacua <m.r.s...@gmail.com> a écrit :
>>
>> One of the core design issues with DRF is that everything
>> is based around a queryset. Even if the set is just one item.
>
> This sounds like an easy troll.
> A lot of code from DRF is based around queryset because DRF can introspect and deduce a lot from them.

Maybe could've stated that more objectively. The goal of that email was to
underline it's something you need to keep in mind when working
with DRF: Django's and DRF's approach to list and detail are different
at the core.

--
Melvyn Sopacua