Merge branch 'master' of github.com:agiliq/building-api-django

docs/Documenting-API-with-RAML.rst

@@ -1,7 +1,7 @@
 Documenting API with RAML
 ============================
 
-In this chapater we will see how to use raml for all the views of our API.
+In this chapter we will see how to use raml for all the views of our API.
 
 RAML is an acronym for "RESTful API Modeling Language". It is a YAML based language for describing the RESTful APIs. RAML contains certain sections for describing the APIs. Each section has it's purpose and we'll look into each one of these by using our polls application.
 

docs/access-control.rst

@@ -145,7 +145,7 @@ Also, dont forget to give exemption to :code:`UserCreate` view for authenticatio
         permission_classes = ()
         serializer_class = UserSerializer
 
-Note the :code:`authentication_classes = ()` and :code:`permission_classes = ()` to excempt :code:`UserCreate` from global authentication scheme.
+Note the :code:`authentication_classes = ()` and :code:`permission_classes = ()` to exempt :code:`UserCreate` from global authentication scheme.
 
 We want to ensure that tokens are created when user is created in :code:`UserCreate` view, so we update the :code:`UserSerializer`. Change your :code:`serailizers.py` like this
 
@@ -296,4 +296,4 @@ Similarly trying to create choice for someone else's :code:`Poll` will get an er
 Next steps:
 -----------------
 
-In the next chapter we will look at adding tests for our API and serailizers. We will also look at how to use :code:`flake8` and run our tests in a CI environment.
+In the next chapter we will look at adding tests for our API and serializers. We will also look at how to use :code:`flake8` and run our tests in a CI environment.

docs/apis-without-drf.rst

@@ -93,6 +93,6 @@ Why do we need DRF?
 **(DRF = Django Rest Framework)**
 
 We were able to build the API with just Django, without using DRF, so why do we need DRF?
-Almost always, you will need common tasks with your APIs, such as access control, serailization, rate limiting and more.
+Almost always, you will need common tasks with your APIs, such as access control, serialization, rate limiting and more.
 
 DRF provides a well thought out set of base components and convenient hook points for building APIs. We will be using DRF in the rest of the chapters.

docs/introduction.rst

@@ -1,17 +1,17 @@
 Introductions
 =================
 
-*Building APIs with Django and Django Rest Framework* starts where the `Django "Polls" tutorial <https://docs.djangoproject.com/en/2.0/intro/tutorial01/>`_ stops, and takes you through building the polls app, but this time using APIs. You will learn the basics of Django Rest Framework including serialisation, views, generic views, viewsets, testing, access control. You will also learn about API documentation using swagger and raml.
+*Building APIs with Django and Django Rest Framework* starts where the `Django "Polls" tutorial <https://docs.djangoproject.com/en/2.0/intro/tutorial01/>`_ stops, and takes you through building the polls app, but this time using APIs. You will learn the basics of Django Rest Framework including serialization, views, generic views, viewsets, testing, access control. You will also learn about API documentation using swagger and raml.
 
 Who is this book for?
 -------------------------
 
-If you have finished the Django "Polls" tuorial, and want to learn using DRF to build APIs, this book is perfect for you. This book assume some knowledge of Django and Python, which you should have built if you have finished the "Poll" turtorial. No existing knowledge of DRF is assumed.
+If you have finished the Django "Polls" tutorial, and want to learn using DRF to build APIs, this book is perfect for you. This book assumes some knowledge of Django and Python, which you should have built if you have finished the "Poll" turtorial. No existing knowledge of DRF is assumed.
 
 
 How to read this book?
 -------------------------
 
-The chapters are meant to be read in order. If you have existing knowledge of some chapters, you can quickly go throough that chapter, but I highly recommend reading them in order as each chapter builds on the previous.
+The chapters are meant to be read in order. If you have existing knowledge of some chapters, you can quickly go through that chapter, but I highly recommend reading them in order as each chapter builds on the previous.
 
 

docs/more-views-and-viewsets.rst

@@ -10,10 +10,10 @@ We have three API endpoints
 - :code:`/choices/`
 - :code:`/vote/`
 
-They get the work done, but we can make our API more intutive by nesting them correctly. Our redesigned urls look like this:
+They get the work done, but we can make our API more intuitive by nesting them correctly. Our redesigned urls look like this:
 
 - :code:`/polls/` and :code:`/polls/<pk>`
-- :code:`/polls/<pk>/choices/` to GET the choices for a specfifc poll, and to create choices for a specific poll. (Idenitfied by the :code:`<pk>`)
+- :code:`/polls/<pk>/choices/` to GET the choices for a specific poll, and to create choices for a specific poll. (Idenitfied by the :code:`<pk>`)
 - :code:`/polls/<pk>/choices/<choice_pk>/vote/` - To vote for the choice identified by :code:`<choice_pk>` under poll with :code:`<pk>`.
 
 Changing the views
@@ -145,7 +145,7 @@ And for :code:`CreateVote`,
             else:
                 return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
 
-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.
+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 similar to our earlier :code:`APIView`, where in we are passing the data to a serializer, and saving or returning an error depending on whether the serializer is valid.
 
 Introducing Viewsets and Routers
 -----------------------------------
@@ -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.
 

docs/serailizers.rst

@@ -1,8 +1,8 @@
-Serialiering and Deserializing Data
+Serializing and Deserializing Data
 ========================================
 
 DRF makes the process of building web API's simple and flexible. With batteries included,
-it comes with well designed base classes to allows to serialize and deserialize data.
+it comes with well designed base classes which allows us to serialize and deserialize data.
 
 
 Serialization and Deserialization

docs/setup-models-admin.rst

@@ -109,7 +109,7 @@ The above models have been designed in such a way that, it would make our API bu
 Activating models
 ----------------------
 
-With the simple lines of code in the 'models.py' Django can create a database schema and a Python database-access API which has the capablity to access the objects of Poll, Choice, Vote. To create the database tables to our models, 'rest_framework' and 'pollsapi' app needs to be added to the "INSTALLED_APPS" in the 'django_pollsapi/settings' file.
+With the simple lines of code in the 'models.py' Django can create a database schema and a Python database-access API which has the capability to access the objects of Poll, Choice, Vote. To create the database tables to our models, 'rest_framework' and 'pollsapi' app needs to be added to the "INSTALLED_APPS" in the 'django_pollsapi/settings' file.
 
 .. code-block:: python
 

docs/swagger.rst

@@ -1,7 +1,7 @@
 Documenting APIs with Swagger
 =============================
 
-In this chapater we will see how to use swagger for all the views of our API.
+In this chapter we will see how to use swagger for all the views of our API.
 
 Swagger is a tool used to understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. In simple terms, with swagger you can see what all API end points are available for a web application. You can use swagger for testing the requests and responses of the API endpoints.
 
@@ -156,7 +156,7 @@ Now open the swagger UI in your browser from http://localhost:8000/ and enter ht
 Note
 --------
 
-You may get errors while running both swagger and the JSON file with SimpleHTTPServer locally saying "It may not have the appropriate access-control-origin settings." That's because the server running swagger doesn't have access over the other server. In order to resolve this, we need give the access control. We can do this by writing a custom class and running the server using this. We'll write the custom class in a seperate file called simple-cors-http-server.py.
+You may get errors while running both swagger and the JSON file with SimpleHTTPServer locally saying "It may not have the appropriate access-control-origin settings." That's because the server running swagger doesn't have access over the other server. In order to resolve this, we need give the access control. We can do this by writing a custom class and running the server using this. We'll write the custom class in a separate file called simple-cors-http-server.py.
 
 
 .. code-block:: python

docs/testing-and-ci.rst

@@ -2,7 +2,7 @@ Testing and Continuous Integeration
 ==========================================
 
 
-In this chapater we will add test to our API.
+In this chapter we will add test to our API.
 
 DRF provides a few important classes which makes testing APIs simpler. We will be using these classes later in the chapter in our tests.
 
@@ -14,7 +14,7 @@ Now lets us write test cases to our polls application.
 
 Creating Test Requests
 ------------------------
-Django's 'Requestfactory' has the capability to create request instances which allow us in testing view functions induvidually. Django Rest Framework has a class called 'APIRequestFactory' which extends the standard Django's  'Requestfactory'. This class contains almost all the http verbs like .get(), .post(), .put(), .patch() et all.
+Django's 'Requestfactory' has the capability to create request instances which allow us in testing view functions individually. Django Rest Framework has a class called 'APIRequestFactory' which extends the standard Django's  'RequestFactory'. This class contains almost all the http verbs like .get(), .post(), .put(), .patch() et all.
 
 Syntax for Post request:
 
@@ -258,7 +258,7 @@ Time to celebrate with the API :)
 Continuous integration with CircleCI
 ---------------------------------------
 
-We have the tests, but we also want it to run on every commit. If you are using Github, CircleCI provides a very well in integrated servive to run you tests. We will use Circleci. v2
+We have the tests, but we also want it to run on every commit. If you are using Github, CircleCI provides a very well in integrated service to run your tests. We will use Circleci. v2
 
 We can configure our application to use Circle CI  by adding a file named :code:`.circleci/circle.yml` which is a YAML(a human-readable data serialization format) text file. It automatically detects when a commit has been made and pushed to a Github repository that is using CircleCI, and each time this happens, it will try to build the project and runs tests. The build failure or success is notified to the developer.
 

docs/views-and-generic-views.rst

@@ -200,7 +200,7 @@ Let us add the view to create choices and for voting. We will look more closely
         serializer_class = VoteSerializer
 
 
-Conect the new apiviews to urls.py.
+Connect the new apiviews to urls.py.
 
 .. code-block:: python