mirror of
https://github.com/encode/django-rest-framework.git
synced 2025-02-03 05:04:31 +03:00
Use named links in tutorial docs
This commit is contained in:
parent
5611769162
commit
575630d7c3
|
@ -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.
|
||||
|
||||
[json-url]: http://example.com/api/items/4.json
|
||||
[2]: 1-serialization.md
|
||||
[3]: http://127.0.0.1:8000/
|
||||
[4]: ../topics/browsable-api.md
|
||||
[5]: 3-class-based-views.md
|
||||
[devserver]: http://127.0.0.1:8000/
|
||||
[browseable-api]: ../topics/browsable-api.md
|
||||
[tut-1]: 1-serialization.md
|
||||
[tut-3]: 3-class-based-views.md
|
|
@ -1,6 +1,6 @@
|
|||
# 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
|
||||
|
||||
|
@ -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.
|
||||
|
||||
[1]: http://en.wikipedia.org/wiki/Don't_repeat_yourself
|
||||
[2]: 4-authentication-permissions-and-throttling.md
|
||||
[dry]: http://en.wikipedia.org/wiki/Don't_repeat_yourself
|
||||
[tut-4]: 4-authentication-permissions-and-throttling.md
|
||||
|
|
|
@ -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
|
|
@ -1,9 +1,11 @@
|
|||
# Tutorial 5 - Relationships & Hyperlinked APIs
|
||||
|
||||
**TODO**
|
||||
|
||||
* Create BlogPost model
|
||||
* Demonstrate nested 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
|
||||
|
|
|
@ -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):
|
||||
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...
|
||||
|
||||
resources.py
|
||||
|
||||
|
@ -28,6 +25,7 @@ resources.py
|
|||
permissions_classes = (permissions.IsAuthenticatedOrReadOnly,)
|
||||
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:
|
||||
|
||||
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.
|
||||
* 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
|
Loading…
Reference in New Issue
Block a user