(docs): add more links to certain references in the docs

- Mostly in Backstory, also in Compatibility

README.md

@@ -26,7 +26,7 @@ It is expected that you already have Django installed
 _This was originally used in an older Django 1.5 codebase with Python 2.7._
 
 Should work with Django 1.x with Python 2.7 and Python 3.x
-- The `@require_auth` decorator will have some problems with Django 2.x as `request.user.is_authenticated()` has been removed and replaced with `request.user.is_authenticated`
+- The `@require_auth` decorator will have some problems with Django 2.x as [`request.user.is_authenticated()` has been removed and replaced with `request.user.is_authenticated`](https://docs.djangoproject.com/en/2.0/releases/2.0/#features-removed-in-2-0)
 - Likely works with Django 0.95-0.99 as well, didn't check any earlier versions' release notes
 - `2to3` shows that there is nothing to change, so should be compatible with Python 3.x
 - Have not confirmed if this works with earlier versions of Python.
@@ -149,7 +149,7 @@ I'd encourage you to read the source code, since it's shorter than this README :
 
 This library was built while I was working on [Yorango](https://github.com/Yorango)'s ad-hoc API and transitioning from an MPA to an SPA. Instead of repeating lots of authentication, authorization, and validation code for every request, I wanted to DRY it up more using decorators or middleware. Decorators would allow us to have early returns with proper HTTP Status Codes for invalid requests. Request code became easier to reason about as a result, guaranteeing it would only execute after authz/authn/etc, and much less prone to accidental bugs, e.g. security issues due to forgetting an authorization check. `@method_exclusive`, `@require_auth`, and a few more project-specific decorators were born out of some of those needs.
 
-Validation was a bit more difficult, as we had many existing Django `Form`s in the MPA, wanted to re-use the classes and validation code we already had in our API instead of re-writing, and wanted to keep things in the same idiomatic style. Django REST Framework has the concept of ["Validators"](http://www.django-rest-framework.org/api-guide/validators/), but it is explicitly different from Django's standard `Form` interface and requires you to buy-in to other parts of DRF to use, like Serializers. `@clean_form` was born to address those needs. Later `@clean_forms` was made to address the case of multiple of the same form in one API request (e.g. for bulk creation), somewhat similar to how a Django `FormSet` might work, but much simpler and requiring a lot less coupling of front and back end code.
+Validation was a bit more difficult, as we had many existing [Django `Form`s](https://docs.djangoproject.com/en/2.0/ref/forms/api/#django.forms.Form) in the MPA, wanted to re-use the classes and validation code we already had in our API instead of re-writing, and wanted to keep things in the same idiomatic style. [Django REST Framework has the concept of "Validators"](http://www.django-rest-framework.org/api-guide/validators/), but it is explicitly different from Django's standard `Form` interface and requires you to buy-in to other parts of DRF to use, like Serializers. `@clean_form` was born to address those needs. Later `@clean_forms` was made to address the case of multiple of the same form in one API request (e.g. for bulk creation), somewhat similar to how a [Django `FormSet`](https://docs.djangoproject.com/en/2.0/topics/forms/formsets/) might work, but much simpler and requiring a lot less coupling of front and back end code.
 
 These were all used in production with great results, some API methods having just 1 decorator and others having 3 or more decorators, such as: