Develop Reference

Why Django rest framework is restful?

I'm now writing my engineering thesis about REST and REST APIs, mostly focusing on Django REST framework as it was the framework we used in our engineering project. I just finished writing about the guidelines for API to be RESTful stated by Roy Fielding and I wanted to start section with implementations of REST architecture in Django REST Framework, but then I realized I don't really know why this framework is RESTful. I know what main paradigms are for API to be RESTful, but I don't know what specific parts of framwork inplements for example that our service is stateless or layered. Maybe someone can pinpoint what parts of django rest framework corresponds to specified guidelines for service to be RESTful ? If It's wrong site to ask this type of question then I'm sorry, but any help would be greatly appreciated.

Let's go through the points that make API a RESTful one
1. Client-server architecture
The very essence of the fact that you are developing a backend server, which is not part of your application UI is the point of this client-server architecture.
Every app you develop with Django Rest Framework (from now on DRF) is a backend API, which is separated from the client.
2. Statelessness
I cannot pin point the exact code line that shows why DRF is statelessness but its somewhere deep between Django and the WSGI/ASGI interface.
Somewhere in there you have some kind of code like this:
while True:
request = io.listen_for_request()
response = handle_request(request)
return response
This "very pseudo" code is stateless! why? because we don't save or rely on any information between requests
3. Cacheability
This one is fairly simple, Django and DRF support caching link
4. Layered system
This concept is kinda hard to correlate directly to DRF or Django. This is mainly done through the HTTP protocol.
5. Code on demand (optional)
Servers can temporarily extend or customize the functionality of a client by transferring executable code: for example, compiled components such as Java applets, or client-side scripts such as JavaScript.
Basically Django Templates. It allows you to send forms and pages as part of your endpoints.
6. Uniform Interface
Last but not least, the famous uniform interface. DRF helps you build your REST API interface by creating endpoints with the help of Generic views. Those generic views help you create a full CRUD (create, read...) endpoint on a Django model with little to no effort. The created endpoint follows the Rest API interface of url structure for a resource.

Django DB Design and API Guidance

This is my first Django app, and also my first time building an app, and I am seeking some DB and API guidance. I have an app that functions as an online directory and marketplace. What I aim to do is to provide the app to many different organizations such that the organizations have their own online directory's and marketplace's where they can manage it fully on their own, but that their data is still linked to my database so that I can then operate on the data for machine learning purposes. This is a pretty standard/routine practice, I realize, but I am trying to wrap my head around how best to make it work. For each organization, would there just be an instance of the app which would then be a separate app or interface that connects to the original? From my newbie understanding, that is essentially what an API is, correct?

Since it's an API, I wouldn't separate the DBs or the instances, neither make several Django apps, but I would have a dedicated clients model/table in the DB, which would store encoded API keys for each of your organizations.
Each client makes its request to your API by authenticating and using their API key, and the Django views answer only with the data linked to the client, as other DB tables have a foreign key to clients.
Sounds pretty standard and RESTful to me.
Some Django / Django REST framework modules like "Django REST Framework API Key" could probably do most of this work for you.

AngularJS + Django - Main advantages and disadvantages

I've developed a couple of apps in Django and need to develop a moderately complex new app now. I've heard about AngularJS and I'm considering to use it in my new web app.
From research I have done so far, it seems like the main benefit of using Angular compared to plain Django is a better user experience. Are there any other major benefits that I need to take into account?
I would imagine the disadvantage of this is increased development time. Assuming I get past the Angular learning curve, how much longer will it take to develop the app in Django + Angular than purely in Django? (For instance 150% longer)
One last question is about using Django as the API framework. Effectively, I'm not using all of Django's features, but only a subset. Given this, is Django a good framework to create the API in? What are other alternatives should I consider?

Currently using a similar architecture for an app.
Backend is in Django and I'm using Django Rest Framework (DRF) to create REST resources. It's a highly powerful and customisable REST framework to create API resources.
From my understanding and experience, DRF works very well with any abstracted front end. So you can use the same APIs for any client be it browser or mobile apps. You can also serve the front end content in the same context as the Django backend or even separated. DRF has authentication methods for both types.
Resources: http://www.django-rest-framework.org/
As for learning curve, AngularJS isn't that difficult if you have basic understanding of the concepts of MV* as well as JavaScript. I won't be able to give you an exact time estimate but for me both methods would have lasted as long as each other.

Multi tier architecture implementation on Python

I need to create web application, which can be reached by user as regular web site and as XML-RPC web service. Also web site should have mobile version. I'm planning to use next technologies:
Django (for web frontends (regular and mobile)).
Pyramid (for web service).
SQLAlchemy, Memcached (for persistence level)
Later other projects can reach this data and providing logic, so I think it is better to make two tiers. I see it in next way:
Tier 1. Main logic service level. This level will provide API for frontend applications (Django powered web site, for example).
Tier 2. Different mostly end client applications (web site, API for remote client devices).
For communication between this tiers I'm planning to use XML-RPC protocol.
In this case it will be easy to scale it and add new front end application or connect another projects to this (I believe it).
I have main question, -- what can I use to make it easy build first tier? Maybe there is some framework good for that?
And what do you think about this whole architecture. Because I'm filling that I'm thinking in Java terms developing in Python. Maybe there is some another idioms in Python world for such situations.
Thanks for you time and help.
P. S.
Some links for reading are welcome.

This architecture really makes no sense. You're using Django, a full-stack web framework, for the front end, but not using it for the database. And you're using Pyramid, another full-stack web framework, for the web service side, thus ensuring that you duplicate all the business logic.
Much as I am an advocate of Django, I would say it has no place in your architecture. It looks like the only thing you're really using it for is URL routing and templates, both of which Pyramid does itself fine - you can even use Jinja2, which is based on Django's template language, as the template language in Pyramid if you like.
Doing it this way means that you can share the business logic between the front-end and web service code, since you'll almost certainly find that a lot of it will be the same.
I must say also that I don't understand the division into tiers, which you have described as separate from the front-end/web service division. To me, the web service is the second tier. It makes no sense to have a further division.

You should checkout the Turbogears framework as it is composed of several popular components: ORM with sqlalchemy, pylons for logic and support for WSGI, permits support for several templating engines for the frontend... endless.
I use it for several web-services behind AJAX-enabled front-ends (like Flex-based apps, among others). You can front end the TG2-based webapp with apache or your favorite WSGI-enabled web server too.
Checkout their website since they have a tutorial to setup a wiki in 20 minutes.
Cheers!

Package for creating and validating HTML forms in Python? - to be used in Google Appengine

Is there a well maintained package available in Python for creating and validating HTML forms? I will deploying it finally on Google Appengine.

You can use Django form validation on GAE storage via db.djangoforms.ModelForm.
To smoothly integrate client-side Dojo functionality with Django server-side web apps, I'd look at dojango, which does work fine with GAE (as well as without). However, dojango (currently at release 0.3.1) does not yet automatically provide client-side validation of Django forms -- that's on the roadmap for the forthcoming release 0.4 of dojango, but I have no idea about the timeframe in which you could expect it.

For client-side validation, check http://plugins.jquery.com/search/node/form+validate;
for server-side, actually ALMOST every web framework (web.py, django, etc.) has its own form generation as well as validation lib for you to use.

AppEngine includes Django's form framework (or a variation thereof), which I find very nice. It also plays well with your ORM (i.e. getting forms for models is very DRY). The only potential problem is the lack of client-side validation.