@@ -125,11 +125,11 @@ We don't necessarily need to add these extra url patterns in, but it gives us a
## How's it looking?
Go ahead and test the API from the command line, as we did in [tutorial part 1][2]. Everything is working pretty similarly, although we've got some nicer error handling if we send invalid requests.
Go ahead and test the API from the command line, as we did in [tutorial part 1][tut-1]. Everything is working pretty similarly, although we've got some nicer error handling if we send invalid requests.
**TODO: Describe using accept headers, content-type headers, and format suffixed URLs**
Now go and open the API in a web browser, by visiting [http://127.0.0.1:8000/][3]."
Now go and open the API in a web browser, by visiting [http://127.0.0.1:8000/][devserver]."
**Note: Right now the Browseable API only works with the CBV's. Need to fix that.**
...
...
@@ -137,15 +137,15 @@ Now go and open the API in a web browser, by visiting [http://127.0.0.1:8000/][3
Because the API chooses a return format based on what the client asks for, it will, by default, return an HTML-formatted representation of the resource when that resource is requested by a browser. This allows for the API to be easily browsable and usable by humans.
See the [browsable api][4] topic for more information about the browsable API feature and how to customize it.
See the [browsable api][browseable-api] topic for more information about the browsable API feature and how to customize it.
## What's next?
In [tutorial part 3][4], we'll start using class based views, and see how generic views reduce the amount of code we need to write.
In [tutorial part 3][tut-3], we'll start using class based views, and see how generic views reduce the amount of code we need to write.
We can also write our API views using class based views, rather than function based views. As we'll see this is a powerful pattern that allows us to reuse common functionality, and helps us keep our code [DRY][1].
We can also write our API views using class based views, rather than function based views. As we'll see this is a powerful pattern that allows us to reuse common functionality, and helps us keep our code [DRY][dry].
## Rewriting our API using class based views
...
...
@@ -147,7 +147,7 @@ Using the mixin classes we've rewritten the views to use slightly less code than
Wow, that's pretty concise. We've got a huge amount for free, and our code looks like good, clean, idomatic Django.
Next we'll move onto [part 4 of the tutorial][2], where we'll take a look at how we can customize the behavior of our views to support a range of authentication, permissions, throttling and other aspects.
Next we'll move onto [part 4 of the tutorial][tut-4], where we'll take a look at how we can customize the behavior of our views to support a range of authentication, permissions, throttling and other aspects.
In REST framework Resources classes are just View classes that don't have any handler methods bound to them. This allows us to seperate out the behaviour of the classes from how that behaviour should be bound to a set of URLs.
# Tutorial 6 - Resources
For instance, given our serializers
Resource classes are just View classes that don't have any handler methods bound to them. The actions on a resource are defined,
serializers.py
This allows us to:
class BlogPostSerializer(URLModelSerializer):
class Meta:
model = BlogPost
* Encapsulate common behaviour accross a class of views, in a single Resource class.
* Seperate out the actions of a Resource from the specfics of how those actions should be bound to a particular set of URLs.
class CommentSerializer(URLModelSerializer):
class Meta:
model = Comment
## Refactoring to use Resources, not Views
We can re-write our 4 sets of views into something more compact...
For instance, we can re-write our 4 sets of views into something more compact...
