Use named links in tutorial docs

This commit is contained in:
Tom Christie 2012-09-19 13:02:10 +01:00
parent 5611769162
commit 575630d7c3
5 changed files with 32 additions and 28 deletions

View File

@ -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? ## 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** **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.** **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. 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? ## 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.
[json-url]: http://example.com/api/items/4.json [json-url]: http://example.com/api/items/4.json
[2]: 1-serialization.md [devserver]: http://127.0.0.1:8000/
[3]: http://127.0.0.1:8000/ [browseable-api]: ../topics/browsable-api.md
[4]: ../topics/browsable-api.md [tut-1]: 1-serialization.md
[5]: 3-class-based-views.md [tut-3]: 3-class-based-views.md

View File

@ -1,6 +1,6 @@
# Tutorial 3: Class Based Views # Tutorial 3: Class Based Views
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 ## 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. 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.
[1]: http://en.wikipedia.org/wiki/Don't_repeat_yourself [dry]: http://en.wikipedia.org/wiki/Don't_repeat_yourself
[2]: 4-authentication-permissions-and-throttling.md [tut-4]: 4-authentication-permissions-and-throttling.md

View File

@ -1,3 +1,5 @@
[part 5][5] # Tutorial 4: Authentication & Permissions
[5]: 5-relationships-and-hyperlinked-apis.md Nothing to see here. Onwards to [part 5][tut-5].
[tut-5]: 5-relationships-and-hyperlinked-apis.md

View File

@ -1,9 +1,11 @@
# Tutorial 5 - Relationships & Hyperlinked APIs
**TODO** **TODO**
* Create BlogPost model * Create BlogPost model
* Demonstrate nested relationships * Demonstrate nested relationships
* Demonstrate and describe hyperlinked relationships * Demonstrate and describe hyperlinked relationships
[part 6][1] Onwards to [part 6][tut-6].
[1]: 6-resource-orientated-projects.md [tut-6]: 6-resource-orientated-projects.md

View File

@ -1,18 +1,15 @@
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): * Encapsulate common behaviour accross a class of views, in a single Resource class.
class Meta: * Seperate out the actions of a Resource from the specfics of how those actions should be bound to a particular set of URLs.
model = BlogPost
class CommentSerializer(URLModelSerializer): ## Refactoring to use Resources, not Views
class Meta:
model = Comment
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...
resources.py resources.py
@ -28,6 +25,7 @@ resources.py
permissions_classes = (permissions.IsAuthenticatedOrReadOnly,) permissions_classes = (permissions.IsAuthenticatedOrReadOnly,)
throttle_classes = (throttles.UserRateThrottle,) throttle_classes = (throttles.UserRateThrottle,)
## Binding Resources to URLs explicitly
The handler methods only get bound to the actions when we define the URLConf. Here's our urls.py: The handler methods only get bound to the actions when we define the URLConf. Here's our urls.py:
comment_root = CommentResource.as_view(actions={ comment_root = CommentResource.as_view(actions={
@ -71,6 +69,8 @@ We've reached the end of our tutorial. If you want to get more involved in the
* Contribute on GitHub by reviewing issues, and submitting issues or pull requests. * Contribute on GitHub by reviewing issues, and submitting issues or pull requests.
* Join the REST framework group, and help build the community. * Join the REST framework group, and help build the community.
* Follow me [on Twitter](https://twitter.com/_tomchristie) and say hi. * Follow me [on Twitter][twitter] and say hi.
Now go build something great. **Now go build some awesome things.**
[twitter]: https://twitter.com/_tomchristie