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.
Related
I have been working on a program in python that I want to make available to paid subscribers via REST. I'm currently thinking of having the frontend made in Wordpress and then host the backend somewhere else.
In wordpress there are a bunch of plugins to handle paid subscribers and so on and everything seems great but my concern is how do I verify this on the backend that is hosted somewhere else?
If I use Django, is there any way I can make some kind of call to the Wordpress server(?) and verify that the user that is trying to fetch items are an paid subscriber?
I made a Diagram to kind of show what I mean. Basically B should only answer back with items if the caller A is a paid subscriber.
I've read that it is possible to generate an API key that will be needed in order to fetch data from the API, I've also read ways of hiding this call from the frontend to the backend from the user by using some kind of relay on wordpress. Might be wrong here.
Is there any preferred way of doing this?
Is Django REST & Wordpress suitable options to do this?
You can do that using the Django REST framework(DRF) which is used for such purpose for making the rest API's.
As per your query i would suggest you to the DRF to read the data from wordpress database and perform the validation on top of it.
Here are some links that you can use for reference :-
https://pythonrepo.com/repo/istrategylabs-django-wordpress-python-third-party-apis-wrappers
https://www.ianlewis.org/en/administer-wordpress-django-admin
In programming almost anything is possible. However, since wordpress is built in php I would not say that it would be possible to work directly with it. But, (MAYBE) you can connect the wordpress database to django for READ only and create an api.
How I would do it if I had this task:
Connect Django to an existing db (your wordpress db):
Django itself teaches you how to connect with a legacy database from its documentation.
Django comes with a utility called inspectdb that can create models by
introspecting an existing database. You can view the output by running
this command:
$ python manage.py inspectdb
Save this as a file by using standard Unix output redirection:
$ python manage.py inspectdb > models.py
**This feature is meant as a shortcut, not as definitive model generation.**
Since you created the models you can create your endpoints:
Create you serializers and viewsets from the models that was auto-generated by django from your wordpress db.
Display the data you need such as the user data you need to fetch ex:paid_subscriber = True or paid_subscriber = 1. Certainly it will be there.
I think the only issue you will have is to connect with the wordpress database. After you have done this in django nothing can stop you to create endpoints with django-rest-framework displaying the data it has.
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.
As the basic framework core:
Request Lifecycle REST
Routing
Requests & Input
Views & Responses
Controllers
Errors & Logging
And these features would make our dev easy and fast:
Authentication
Cache
Core Extension
Events
Facades
Forms & HTML
IoC Container
Mail
Pagination
Queues
Security
Session
SSH
Templates
Unit Testing
Validation
And really good support for MongoDB.
Is there any such framework?
There is a fork of Django that supports non relational databases. For my own projects I prefer to use a hybrid: standard (relational) Django, with MongoEngine for entities I want to store in MongoDB. The syntax is almost identical to django.db models.
I'm kinda confused by the desire of a "REST lifecycle" combined with features like "Session", "Input", etc.
For a general purpose Web/API application you might want to check out on Flask and Flask-PyMongo. Could be a good match for your use case.
If you're looking into building a RESTful Web Service, then the Eve REST API framework (which is powered by Flask and supports MongoDB out of the box) could be a good choice. You can then peek into the source of extensions like Eve-Docs to learn how to, eventually, integrate the webservice with HTML/static/dynamic pages (Flask style.)
Try Django.. im not sure but worth trying
I'm trying to build a niche social network like Instagram as a Python/Django application.
So the things I need, regarding architecture, are (I guess):
REST API (e.g. api.mystagram.com).
Public website (www.mystagram.com or mystagram.com).
URL shortener (e.g. mystagr.am).
Android app
iPhone app
Windows Phone app
...
Before this I only built simple to some less-simple websites, but never extremely complex with own custom APIs or so. I have never build my own REST API before (I have used other REST APIs though) or even built an Android/iPhone app and distributed it in the Play Store/App Store (I have made some typical hello world examples though).
So, the most important thing to me seems to create a kick-ass REST API first and proceed from there. I am blocked however by a few questions.
How should I organize the projects for the public website and REST API? Should these be separate Django projects or should I create only one Django project and add both the public website and REST API as an internal Django module?
Should the public website also make use of the REST API? Or is it better to just use the plain Django models for this?
Thanks in advance for any help! If somebody knows some great presentations or so on this topic (architecture), always welcome!
Kind regards,
Kristof
Django REST Framework
https://github.com/tomchristie/django-rest-framework
Very well maintained, great documentation, easy to use.
I think Tastypie will do what you want. And its simple and easy. Check this out - http://django-tastypie.readthedocs.org/en/latest/!
To Answer your first question, It would be good practice to put public web site and REST APIs into one django project. Now days every web application contains public web site as well as rest apis for mobile app. So it would be easier to maintain both website and rest apis if they both in one application. Below is Django REST Framework link.
https://github.com/tomchristie/django-rest-framework
For second question, Yes you can use rest apis in website also. But in general you don't need to do it. In most of the cases django model works for you.
Here is the situation:
We use Flask for a website application development.Also on the website sever, we host a RESTful service. And we use Flask-login for as the authentication tool, for BOTH the web application access and the RESTful service (access the Restful service from browsers).
Later, we find that we need to, also, access the RESTful from client calls (python), so NO session and cookies etc. This gives us a headache regarding the current authentication of the RESTful service.
On the web, there exist whole bunch of ways to secure the RESTful service from client calls. But it seems no easy way for them to live together with our current Flask-login tool, such that we do not need to change our web application a lot.
So here are the question:
Is there a easy way(framework) so the RESTful services can support multiple authentication methods(protocols) at the same time. Is this even a good practice?
Many thanks!
So, you've officially bumped into one of the most difficult questions in modern web development (in my humble opinion): web authentication.
Here's the theory behind it (I'll answer your question in a moment).
When you're building complicated apps with more than a few users, particularly if you're building apps that have both a website AND an API service, you're always going to bump into authentication issues no matter what you're doing.
The ideal way to solve these problems is to have an independent auth service on your network. Some sort of internal API that EXCLUSIVELY handles user creation, editing, and deletion. There are a number of benefits to doing this:
You have a single authentication source that all of your application components can use: your website can use it to log people in behind the scenes, your API service can use it to authenticate API requests, etc.
You have a single service which can smartly managing user caching -- it's pretty dangerous to implement user caching all over the place (which is what typically happens when you're dealing with multiple authentication methods: you might cache users for the API service, but fail to cache them with the website, stuff like this causes problems).
You have a single service which can be scaled INDEPENDENTLY of your other components. Think about it this way: what piece of application data is accessed more than any other? In most applications, it's the user data. For every request user data will be needed, and this puts a strain on your database / cache / whatever you're doing. Having a single service which manages users makes it a lot nicer for you to scale this part of the application stack easily.
Overall, authentication is really hard.
For the past two years I've been the CTO at OpenCNAM, and we had the same issue (a website and API service). For us to handle authentication properly, we ended up building an internal authentication service like described above, then using Flask-Login to handle authenticating users via the website, and a custom method to authenticate users via the API (just an HTTP call to our auth service).
This worked really well for us, and allowed us to scale from thousands of requests to billions (by isolating each component in our stack, and focusing on user auth as a separate service).
Now, I wouldn't recommend this for apps that are very simple, or apps that don't have many users, because it's more hassle than it's worth.
If you're looking for a third party solution, Stormpath looks pretty promising (just google it).
Anyhow, hope that helps! Good luck.