Skip to content

Commit

Permalink
Merge branch 'master' of github.com:agiliq/building-api-django
Browse files Browse the repository at this point in the history
  • Loading branch information
shabda committed Mar 18, 2018
2 parents d58f50e + d4646dd commit 06d823d
Show file tree
Hide file tree
Showing 3 changed files with 11 additions and 11 deletions.
6 changes: 3 additions & 3 deletions docs/access-control.rst
Original file line number Diff line number Diff line change
Expand Up @@ -136,7 +136,7 @@ Run :code:`python manage.py migrate` to create the new tables.
)
}
Also, dont forget to give excemption to :code:`UserCreate` view fro authentication by overriding the global setting. The :code:`UserCreate` should look as follows.
Also, dont forget to give exemption to :code:`UserCreate` view for authentication by overriding the global setting. The :code:`UserCreate` in :code:`polls/apiviews.py` should look as follows.

.. code-block:: python
Expand Down Expand Up @@ -177,7 +177,7 @@ The login API

Since we have added :code:`rest_framework.authentication.TokenAuthentication`, we will need to set an header like this :code:`Authorization: Token c2a84953f47288ac1943a3f389a6034e395ad940` to auhenticate. We need an API where a user can give their username and password, and get a token back.

We will not be adding a serailizer, because we never save a token using this API.
We will not be adding a serializer, because we never save a token using this API.

Add a view and connect it to urls.

Expand Down Expand Up @@ -209,7 +209,7 @@ Add a view and connect it to urls.
# ...
]
Do you a POST with a correct username and password, and you will get a response like this.
Do a POST with a correct username and password, and you will get a response like this.

.. code-block:: json
Expand Down
12 changes: 6 additions & 6 deletions docs/more-views-and-viewsets.rst
Original file line number Diff line number Diff line change
Expand Up @@ -59,8 +59,8 @@ And change your urls.py to a nested structure.
#...
urlpatterns = [
path("polls/<int:pk>/choices/", ChoiceList.as_view(), name="polls_list"),
path("polls/<int:pk>/choices/<int:choice_pk>/vote/", CreateVote.as_view(), name="polls_list"),
path("polls/<int:pk>/choices/", ChoiceList.as_view(), name="choice_list"),
path("polls/<int:pk>/choices/<int:choice_pk>/vote/", CreateVote.as_view(), name="create_vote"),
]
Expand Down Expand Up @@ -104,7 +104,7 @@ Lets get back to :code:`ChoiceList`.
#...
urlpatterns = [
# ...
path("polls/<int:pk>/choices/", ChoiceList.as_view(), name="polls_list"),
path("polls/<int:pk>/choices/", ChoiceList.as_view(), name="choice_list"),
]
# views.py
Expand Down Expand Up @@ -145,14 +145,14 @@ And for :code:`CreateVote`,
else:
return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
We pass on poll id and choice id. We subclss this from :code:`APIView`, rather than a generic view, because we competely customize the behaviour. This is similiar to our earlier :code:`APIView`, where in we are passing the data to a serializer, and savig or returnning an error depending on whether the serializer is valid.
We pass on poll id and choice id. We subclass this from :code:`APIView`, rather than a generic view, because we competely customize the behaviour. This is similiar to our earlier :code:`APIView`, where in we are passing the data to a serializer, and saving or returnning an error depending on whether the serializer is valid.

Introducing Viewsets and Routers
-----------------------------------

Our urls are looking good, and we have a views with very little code duplication, but we can do better.

The :code:`/polls/` and :code:`/polls/<pk>/` urls require two view classes, with the same seralizer and base queryset. We can group them into a viewset, and connect the to the urls using a router.
The :code:`/polls/` and :code:`/polls/<pk>/` urls require two view classes, with the same serializer and base queryset. We can group them into a viewset, and connect them to the urls using a router.

This is what it will look like:

Expand Down Expand Up @@ -200,7 +200,7 @@ We have seen 4 ways to build API views until now

So which one should you use when? My rule of thumb is,

- Use code:`viewsets.ModelViewSet` when you are goin to allow all or most of crud operations on a model.
- Use :code:`viewsets.ModelViewSet` when you are goin to allow all or most of crud operations on a model.
- Use :code:`generics.*` when you only want to allow some operations on a model
- Use :code:`APIView` when you want to completely customize the behaviour.

Expand Down
4 changes: 2 additions & 2 deletions docs/views-and-generic-views.rst
Original file line number Diff line number Diff line change
Expand Up @@ -207,8 +207,8 @@ Conect the new apiviews to urls.py.
# ...
urlpatterns = [
# ...
path("choices/", ChoiceList.as_view(), name="polls_list"),
path("vote/", CreateVote.as_view(), name="polls_list"),
path("choices/", ChoiceList.as_view(), name="choice_list"),
path("vote/", CreateVote.as_view(), name="create_vote"),
]
Expand Down

0 comments on commit 06d823d

Please sign in to comment.