#DRF  #API  #Django 

REST API

REpresentational State Transfer API (Application Programming Interface)

Its an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other.

  • It provides a set of principles/rules for building web services that used HTTP as a communication protocol.
  • An API that follows REST standard are called as RESTful API
  • GET, POST, PATCH, PUT and DELETE

Advantages of REST APIs

  • They are very scalable as the client and server are decoupled easing to scale in the future.
  • Simple, standardized, and easy to use.
  • Uses already existing HTTP features.
  • They have high performance because of their cache capabilities.
  • Allows Standard-based protection with the use of OAuth protocols to verify REST requests.
  • Brings flexibility by serializing data in XML or JSON format.

Advantages of Using Django Rest Framework

https://medium.com/@devsumitg/the-power-of-django-rest-framework-streamline-your-api-development-387be93a8acb

  • Built-in support for serialization and deserialization of complex data types.
  • Comprehensive `authentication and authorization mechanisms.
  • Robust request handling with support for various HTTP methods.
  • Modular and reusable code with class-based views and viewsets.
  • Extensive documentation and a large community for support and guidance.
  • Seamless integration with Django ORM for database operations.
  • Testability with built-in testing tools.

REST Architectural Constraints

REST defines 6 architectural constraints which make any web service – a true RESTful API.

1. Client–server
2. Stateless
3. Cacheable
4. Layered system
5. Uniform interface
6. Code on demand (optional)
  • Client–server
    • The client and server application are separated, allowing then evolve independently without any dependency on each other.
    • A client should know only resource URIs and that’s all.
  • Stateless
    • Each request from a client must contain all the information required by the server to carry out the request.
    • The server does not maintain any client context between the request.
    • Server will not store anything about latest HTTP request client made.
    • It will treat each and every request as new. No session, no history.
  • Cacheable
    • Response from the server can be cached to improve performance.
    • Caching can be implemented on the server or client side.
    • In today’s world, caching of data and responses is of utmost important wherever they are applicable/possible.
    • Caching brings performance improvement for client side, and better scope for scalability for a server because the load has reduced.
  • Layered system
    • REST allows you to use a layered system architecture
    • Deploy the APIs on server A, and store data on server B and authenticate requests in Server C.
    • For example. A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way.
  • Uniform interface
    • It suggests that there should be an uniform way of interacting with a given server irrespective of device or type of application (website, mobile app).
    • The method of communication between a client and a server must be uniform. Like GET, POST, DELETE.
    • Any single resource should not be too large and contain each and everything in its representation.
    • Whenever relevant, a resource should contain links (HATEOAS) pointing to relative URIs to fetch related information.
  • Code on demand (optional)
    • Servers can provide executable code or scripts for clients to execute in their context. This constraint is the only one that is optional.
    • Most of the time you will be sending the static representations of resources in form of XML or JSON.
    • But when you need to, you are free to return executable code to support a part of your application
    • e.g. clients may call your API to get a UI widget rendering code. It is permitted.

Methods of REST API

  • REST API offers CRUD operations -
C: Create	--> POST
R: Read         --> GET
U: Update	--> PUT 
D: Delete	--> DELETE

GET Request

  • GET requests is used to retrieve resource/information only
  • Cannot modify resource in any way.
  • It is said to be safe methods.
  • GET APIs should be idempotent.
    • Multiple identical requests must produce the same result every time
    • Until another API (POST or PUT) has changes the resource.

POST Request

  • POST request is used to create new subordinate resources,
  • Eg Create new row in a database table.
  • POST is neither safe nor idempotent,
    • Invoking two identical POST requests will result in two different resources
    • containing the same information (except resource ids).

PUT Request

  • PUT request is used primarily to update an existing resource
  • If the resource does not exist, then API may decide to create a new resource.

Delete Request

  • DELETE request is used to delete the resources (identified by the Request-URI).
  • DELETE operations are idempotent. If you DELETE a resource, it’s removed from the collection of resources.
  • Some may argue that it makes the DELETE method non-idempotent. It’s a matter of discussion and personal opinion.

Install & Setup

# Installation
pip install django
pip install djangorestframework

# Setup
django-admin startproject tutorial
cd tutorial
python manage.py startapp snippets

# RegisterAPP --> setting.py
'snippets.apps.SnippetsConfig',

# RegisterModels  --> snippets/admin.py
admin.site.register(Snippet)