Python एक उच्च-स्तरीय, इंटरप्रिटेड प्रोग्रामिंग भाषा है जो आपको तेज़ी से काम करने और अपने सिस्टम को अधिक प्रभावी ढंग से एकीकृत करने की सुविधा देती है। यह अपने सरल सिंटैक्स के लिए जानी जाती है जो पठनीयता पर जोर देता है और इसलिए प्रोग्राम के रखरखाव की लागत को कम करता है। Python कई प्रोग्रामिंग प्रतिमानों का समर्थन करती है, जिसमें प्रक्रियात्मक (procedural), ऑब्जेक्ट-ओरिएंटेड और कार्यात्मक (functional) प्रोग्रामिंग शामिल हैं।

Poetry, सॉफ़्टवेयर के संदर्भ में, Python में निर्भरता प्रबंधन (dependency management) और पैकेजिंग के लिए एक उपकरण है। यह आपको उन लाइब्रेरीज़ को घोषित करने की अनुमति देता है जिन पर आपका प्रोजेक्ट निर्भर है और यह आपके लिए उन्हें प्रबंधित (इंस्टॉल/अपडेट) करेगा।

संक्षेप में, Python के साथ Poetry का उपयोग करने का अर्थ है एक ऐसा Python-आधारित सॉफ़्टवेयर विकसित करना जिसकी निर्भरताएँ Poetry द्वारा प्रबंधित की जाती हैं।

Python est un langage de programmation interprété de haut niveau qui vous permet de travailler rapidement et d'intégrer vos systèmes de manière plus efficace. Il est connu pour sa syntaxe facile qui met l'accent sur la lisibilité et réduit donc le coût de la maintenance du programme. Python prend en charge plusieurs paradigmes de programmation, y compris la programmation procédurale, orientée objet et fonctionnelle.

Poetry, dans un contexte logiciel, est un outil de gestion des dépendances et de paquetage en Python. Il vous permet de déclarer les bibliothèques dont dépend votre projet et il les gérera (installera/mettra à jour) pour vous.

Ensemble, utiliser Python avec Poetry signifie développer un logiciel basé sur Python dont les dépendances sont gérées par Poetry.

[tool.poetry]
name = "http-apis"
version = "0.1.0"
description = "Http Apis"
authors = ["user "]
license = "MIT"
readme = "README.md"
#packages = [{include = "devops_from_scratch_manual_process"}]

[tool.poetry.dependencies]
#python = "^3.10.6"
python = "^3.11"
sortedcontainers = "^2.4.0"
httpx = "^0.23.0"
pyzmq = "^25.1.0"
fastapi = "^0.97.0"
uvicorn = "^0.22.0"
requests = "^2.31.0"
openai = "^0.27.8"
whitenoise = "^6.2.0"
fontawesomefree = "^6.4.0"
typer = { version = "^0.9.0", extras = ["all"] }

#[tool.poetry.group.dev.dependencies]
#black = "^23.3.0"
#pytest = "7.3.1"

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

यह सोर्स कोड "http-apis" नामक एक प्रोजेक्ट को दर्शाता है। यह संस्करण 0.1.0 है, लेखक का संपर्क ईमेल पता उल्लिखित है, और यह MIT लाइसेंस के अंतर्गत है। प्रोजेक्ट स्पष्ट रूप से कई निर्भरताओं का उपयोग करता है जैसे कि sortedcontainers, httpx, pyzmq, fastapi, uvicorn, requests, openai, whitenoise, fontawesomefree, typer और Python संस्करण 3.11। इस प्रोजेक्ट का बिल्ड सिस्टम "poetry-core" की मांग करता है और निर्माण के लिए "poetry.core.masonry.api" बैकएंड का उपयोग करता है।

संभावित समस्याएँ:

• पैकेज अनुभाग को कमेंट किया गया है, जिसका अर्थ है कि यह फ़ाइल स्पष्ट रूप से यह नहीं बताती है कि वितरण में कौन से पैकेज/मॉड्यूल शामिल किए जाने चाहिए।
• 'dev dependencies' अनुभाग को कमेंट आउट किया गया है, इसलिए यह कोड किसी भी विकास चरण की निर्भरताओं जैसे कि कोड फ़ॉर्मेटिंग के लिए black या परीक्षण के लिए pytest का संकेत नहीं देता है।
• यदि सिस्टम Python संगत नहीं है, तो विशिष्ट Python संस्करण एक समस्या हो सकता है।

सुधार:

• यदि पैकेज और dev dependencies अनुभाग प्रोजेक्ट निर्माण या विकास के लिए आवश्यक हैं, तो उन्हें कमेंट आउट नहीं किया जाना चाहिए, क्योंकि ये योगदानकर्ताओं को अपना वातावरण जल्दी सेट करने में मदद कर सकते हैं।
• Python संस्करण "^3.11" रखने के बजाय, प्रोजेक्ट को नए Python संस्करणों पर भी चलाने की अनुमति देने के लिए ">=3.11" निर्दिष्ट करना बेहतर हो सकता है।
• ReadMe फ़ाइल को इन विवरणों को शामिल करने के लिए अपडेट किया जाना चाहिए ताकि उपयोगकर्ताओं को प्रारंभिक सेटअप और प्रोजेक्ट को समझने में मदद मिल सके।

Ce code source indique un projet appelé "http-apis". Sa version est la 0.1.0, l'adresse e-mail de contact de l'auteur est mentionnée, et il est sous licence MIT. Le projet utilise manifestement une multitude de dépendances telles que sortedcontainers, httpx, pyzmq, fastapi, uvicorn, requests, openai, whitenoise, fontawesomefree, typer et la version 3.11 de Python. Le système de construction de ce projet requiert "poetry-core" et utilise le backend "poetry.core.masonry.api" pour la construction.

Problèmes potentiels :

• La section des paquets est commentée, ce qui signifie que ce fichier n'indique pas explicitement quels paquets/modules doivent être inclus dans la distribution.
• La section 'dépendances de développement' est commentée, donc ce code n'indique aucune dépendance de phase de développement telle que black pour le formatage du code ou pytest pour les tests.
• La version spécifique de Python pourrait poser problème si la version Python du système n'est pas compatible.

Améliorations :

• La section des paquets et des dépendances de développement ne devrait pas être commentée si elle est nécessaire pour la construction du projet ou pour le développement et peut aider les contributeurs à configurer rapidement leur environnement.
• Au lieu de conserver la version Python "^3.11", il serait préférable de spécifier ">=3.11" pour permettre au projet de fonctionner également avec les versions plus récentes de Python.
• Le fichier ReadMe devrait être mis à jour pour inclure ces détails et aider les utilisateurs avec la configuration initiale et la compréhension du projet.

Hurl HTTP अनुरोधों के लिए एक कमांड-लाइन टूल और लाइब्रेरी है। यह आपको एक सरल कमांड के साथ HTTP अनुरोध भेजने की अनुमति देता है और इसका उपयोग अक्सर डेवलपर्स द्वारा API का परीक्षण करने के लिए किया जाता है।

Hurl est un outil en ligne de commande et une bibliothèque pour les requêtes HTTP. Il vous permet d'envoyer des requêtes HTTP avec une commande simple et est souvent utilisé par les développeurs pour tester des API.

cargo install hurl

hurl --help

Run Hurl file(s) or standard input

Usage: hurl [OPTIONS] [input_files]...

Arguments:
  [input_files]...  Sets the input file to use

Options:
      --cacert 
          CA certificate to verify peer against (PEM format)
  -E, --cert 
          Client certificate file and password
      --key 
          Private key file name
      --color
          Colorize output
      --compressed
          Request compressed response (using deflate or gzip)
      --connect-timeout 
          Maximum time allowed for connection [default: 300]
      --connect-to 
          For a request to the given HOST1:PORT1 pair, connect to HOST2:PORT2 instead
  -b, --cookie 
          Read cookies from FILE
  -c, --cookie-jar 
          Write cookies to FILE after running the session (only for one session)
      --error-format 
          Control the format of error messages [default: short] [possible values: short, long]
      --fail-at-end
          Fail at end
      --file-root 
          Set root filesystem to import files [default: current directory]
  -L, --location
          Follow redirects
      --glob 
          Specify input files that match the given GLOB. Multiple glob flags may be used
      --ignore-asserts
          Ignore asserts defined in the Hurl file
  -i, --include
          Include the HTTP headers in the output
  -k, --insecure
          Allow insecure SSL connections
      --interactive
          Turn on interactive mode
      --json
          Output each Hurl file result to JSON
      --max-redirs 
          Maximum number of redirects allowed, -1 for unlimited redirects [default: 50]
  -m, --max-time 
          Maximum time allowed for the transfer [default: 300]
      --no-color
          Do not colorize output
      --no-output
          Suppress output. By default, Hurl outputs the body of the last response
      --noproxy 
          List of hosts which do not use proxy
  -o, --output 
          Write to FILE instead of stdout
      --path_as_is
          Tell Hurl to not handle sequences of /../ or /./ in the given URL path
  -x, --proxy <[PROTOCOL://]HOST[:PORT]>
          Use proxy on given protocol/host/port
      --report-html 
          Generate HTML report to DIR
      --report-junit 
          Write a Junit XML report to FILE
      --resolve 
          Provide a custom address for a specific host and port pair
      --retry 
          Maximum number of retries, 0 for no retries, -1 for unlimited retries [default: 0]
      --retry-interval 
          Interval in milliseconds before a retry [default: 1000]
      --ssl-no-revoke
          (Windows) This option tells Hurl to disable certificate revocation checks. WARNING: this
          option loosens the SSL security, and by using this flag you ask for exactly that.
      --test
          Activate test mode
      --to-entry 
          Execute Hurl file to ENTRY_NUMBER (starting at 1)
  -A, --user-agent 
          Specify the User-Agent string to send to the HTTP server
  -u, --user 
          Add basic Authentication header to each request
      --variable 
          Define a variable
      --variables-file 
          Define a properties file in which you define your variables
      --verbose
          Turn verbose
      --very-verbose
          Turn on verbose output, including HTTP response and libcurl logs
  -h, --help
          Print help
  -V, --version
          Print version

OpenAPI Specification (OAS), जिसे पहले Swagger के नाम से जाना जाता था, RESTful वेब सेवाओं का वर्णन करने, उत्पादन करने, उपभोग करने और विज़ुअलाइज़ करने के लिए मशीन-पठनीय इंटरफ़ेस फ़ाइलों के लिए एक विनिर्देश (specification) है। यह REST API के लिए एक मानक, भाषा-अज्ञेयवादी (language-agnostic) इंटरफ़ेस को परिभाषित करने में मदद करता है, जो मनुष्यों और कंप्यूटरों दोनों को सोर्स कोड, दस्तावेज़ीकरण या नेटवर्क ट्रैफ़िक तक सीधे पहुँच के बिना सेवा क्षमताओं को समझने की अनुमति देता है।

आइए JSON स्कीमा के साथ शुरुआत करें। एक JSON स्कीमा JSON डेटा की संरचना को मान्य करने के लिए एक शक्तिशाली उपकरण है। यह आपके मौजूदा डेटा प्रारूप का स्पष्ट, संक्षिप्त और पढ़ने में आसान (मनुष्यों और मशीनों दोनों के लिए) वर्णन करता है। यह भाषा-अज्ञेयवादी भी है, जिसका अर्थ है कि आप इसे किसी भी प्रोग्रामिंग भाषा के साथ उपयोग कर सकते हैं जिसमें JSON समर्थन है।

अब, OpenAPI विनिर्देश इस तस्वीर में कैसे फिट होते हैं? JSON स्कीमा OpenAPI विनिर्देशों का एक हिस्सा बनाते हैं, जो इसका एक विस्तार है, और REST API का वर्णन और सत्यापन करने के लिए काम आते हैं।

OAS के साथ API बनाकर, डेवलपर्स API को समझ और उपयोग कर सकते हैं, और API का विज़ुअलाइज़ेशन बना सकते हैं, बिना API के सोर्स कोड तक पहुँच प्राप्त किए या व्यापक दस्तावेज़ीकरण पढ़ने की आवश्यकता के। एक अच्छी तरह से डिज़ाइन किया गया OAS API विकास को सरल बनाने में मदद करता है।

TM Forum के OpenAPIs (TMF विनिर्देशों का हिस्सा) OpenAPI विनिर्देशों के वास्तविक दुनिया के उपयोग का एक उदाहरण हैं। वे API का एक सूट हैं जो ग्राहकों और उत्पादों के प्रबंधन से लेकर ऑर्डर और बिलिंग को संभालने तक विभिन्न कार्य प्रदान करते हैं, और विश्व स्तर पर मान्यता प्राप्त मानकों के तहत विकसित किए गए हैं।

आधुनिक सॉफ़्टवेयर विकास में उनकी उपयोगिता के संदर्भ में, वे निम्नलिखित के लिए अत्यंत उपयोगी हैं:

1. दस्तावेज़ीकरण: इंटरैक्टिविटी के साथ दस्तावेज़ीकरण को स्वतः उत्पन्न करने की क्षमता, काम को कम करती है और उपभोक्ताओं और परीक्षण के लिए फायदेमंद है।
2. कोड जनरेशन: OAS विभिन्न भाषाओं में क्लाइंट, सर्वर और टेस्ट केस के निर्माण का समर्थन करता है, जो विकास प्रक्रिया को काफी गति देता है।
3. API डिज़ाइन और योजना: वे डिज़ाइन-फर्स्ट दृष्टिकोण की अनुमति देते हैं, जहाँ आप अपने API की योजना बना सकते हैं और फिर उसे निष्पादित कर सकते हैं।

कुल मिलाकर, OpenAPI विनिर्देश, अपने बुनियादी ढांचे में JSON स्कीमा के साथ, API विकास को तेज़, आसान और अधिक विश्वसनीय बनाकर सॉफ़्टवेयर बनाने के तरीके में एक प्रतिमान बदलाव (paradigm shift) ला रहे हैं।

Spécification OpenAPI (OAS), autrefois connue sous le nom de Swagger, est une spécification pour les fichiers d'interface lisibles par machine pour décrire, produire, consommer et visualiser des services web RESTful. Elle aide à définir une interface standard, indépendante du langage, pour les API REST, ce qui permet aux humains et aux ordinateurs de comprendre les capacités du service sans un accès direct au code source, à la documentation, ou au trafic réseau.

Commençons avec les schémas JSON. Un schéma JSON est un outil puissant pour valider la structure des données JSON. Il décrit votre format de données existant de manière claire, concise et facile à lire (pour les humains et les machines). Il est également indépendant du langage, ce qui signifie que vous pouvez l'utiliser avec n'importe quel langage de programmation qui supporte JSON.

Alors, comment les spécifications OpenAPI s'intègrent-elles dans le tableau ? Les schémas JSON forment une partie des spécifications OpenAPI, qui en sont une extension, et servent à décrire et à valider les API REST.

En créant des API avec OAS, les développeurs peuvent comprendre et utiliser l'API, et former une visualisation de l'API, sans avoir accès au code source de l'API ou la nécessité de lire une documentation extensive. Une OAS bien conçue aide à simplifier le développement des API.

Les OpenAPI du TM Forum (partie des spécifications TMF) sont un exemple d'utilisation réelle des spécifications OpenAPI. Il s'agit d'un ensemble d'API qui fournissent une variété de fonctions, de la gestion des clients et des produits à la manipulation des commandes et de la facturation, et qui sont développées selon des normes mondialement reconnues.

En termes d'utilité dans le développement de logiciels modernes, ils sont extrêmement utiles pour :

1. Documentation: La capacité à générer automatiquement de la documentation, avec interactivité incluse, réduit le travail et est bénéfique pour les consommateurs et les tests.
2. Génération de code: L'OAS soutient la génération de clients, de serveurs et de cas test dans différentes langues, ce qui accélère considérablement le processus de développement.
3. Conception et planification d'API: Ils permettent une approche de conception en premier, où vous pouvez planifier votre API pour ensuite l'exécuter.

En somme, les spécifications OpenAPI, avec les schémas JSON dans leur infrastructure, facilitent un changement de paradigme dans la façon dont nous construisons des logiciels en rendant le développement d'API plus rapide, plus facile et plus fiable.

FastAPI मानक Python टाइप हिंट्स और एसिंक्रोनस प्रोग्रामिंग क्षमताओं पर आधारित Python 3.6+ के साथ API बनाने के लिए एक आधुनिक, तेज़ (उच्च-प्रदर्शन) वेब फ्रेमवर्क है। इसकी मुख्य विशेषताएं तेज़, आसान, पायथोनिक, प्रदर्शन-केंद्रित और मजबूत हैं, जिसमें स्वचालित इंटरैक्टिव API दस्तावेज़ीकरण जैसी सुविधाएं शामिल हैं।

FastAPI वेब भागों के लिए Starlette और डेटा भागों के लिए Pydantic पर बनाया गया है। इसे बहुत तेज़ और उपयोग में आसान होने के लिए डिज़ाइन किया गया है, जिसमें टाइप चेकिंग, IDE एकीकरण और अन्य आधुनिक प्रोग्रामिंग सुविधाओं के लिए उत्कृष्ट समर्थन है। यह मानक Python टाइप हिंट्स का उपयोग करने के लिए बनाए जाने के कारण पूरी तरह से इंटरैक्टिव API तैयार करता है, जो डेटा सत्यापन, क्रमबद्धता (serialization) और दस्तावेज़ीकरण में भी सहायता करते हैं।

FastAPI OpenAPI विनिर्देशों को उत्पन्न करने के लिए Pydantic मॉडल और Python टाइप हिंट्स का उपयोग करता है। OpenAPI विनिर्देश REST API के लिए मानकीकृत प्रारूप हैं जो API की संरचना का वर्णन करने का एक तरीका प्रदान करते हैं, जो सही अनुरोध और प्रतिक्रिया उत्पन्न करने में मदद करता है।

यहाँ एक बुनियादी FastAPI प्रोजेक्ट का एक दिलचस्प कोड उदाहरण है, जिसमें एक API शामिल है जो POST, GET, PATCH, PUT और DELETE एंडपॉइंट्स के साथ-साथ Python Requests लाइब्रेरी पर आधारित क्लाइंट कोड प्रदान करता है:

FastAPI est un framework web moderne, rapide (à haute performance), destiné à la création d'APIs avec Python 3.6+ basé sur les indications de type Python standard et les capacités de programmation asynchrone. Les caractéristiques clés sont la rapidité, la facilité, le côté Pythonic, l'accent sur les performances, et la robustesse, avec des fonctionnalités comme la documentation automatique interactive de l'API.

FastAPI est construit sur Starlette pour les parties web et Pydantic pour les parties de données. Il est conçu pour être très rapide et facile à utiliser, avec un excellent support pour le contrôle de type, l'intégration IDE, et d'autres avantages de la programmation moderne. Il produit une API entièrement interactive grâce à son utilisation des indications de type Python standard, qui aident également à la validation des données, à la sérialisation et à la documentation.

FastAPI utilise les modèles Pydantic et les indications de type Python pour générer des spécifications OpenAPI. Les spécifications OpenAPI sont le format standardisé pour les API REST qui offrent un moyen de décrire la structure de l'API, ce qui aide à générer des requêtes et des réponses correctes.

Voici un exemple de code intéressant d'un projet FastAPI de base, comprenant une API qui sert des points de terminaison POST, GET, PATCH, PUT, et DELETE ainsi qu'un code client basé sur la bibliothèque Python Requests:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float

items = []

@app.post("/items/")
def create_item(item: Item):
    items.append(item.dict())
    return items[-1]

@app.get("/items/")
def read_items():
    return items

@app.patch("/items/{item_id}")
def update_item(item_id: int, item: Item):
    items[item_id] = item.dict()
    return items[item_id]

@app.put("/items/{item_id}")
def replace_item(item_id: int, item: Item):
    items[item_id] = item.dict()
    return items[item_id]

@app.delete("/items/{item_id}")
def delete_item(item_id: int):
    items.pop(item_id)
    return {'Message': 'Item deleted'}

और यहाँ बताया गया है कि आप Python Requests लाइब्रेरी का उपयोग करके इस API का उपभोग कैसे कर सकते हैं:

uvicorn server:app --reload

यह कमांड मानती है कि FastAPI स्क्रिप्ट server.py नामक फ़ाइल में है और इसमें app नामक FastAPI का एक इंस्टेंस शामिल है।

import requests

# POST a new item
requests.post('http://localhost:8000/items/', json={'name': 'item1', 'price': 20.0})

# GET all items
response = requests.get('http://localhost:8000/items/')
print(response.json())

# PATCH an existing item
requests.patch('http://localhost:8000/items/0', json={'name': 'item2', 'price': 30.0})

# PUT (replace) an existing item
requests.put('http://localhost:8000/items/0', json={'name': 'item3', 'price': 40.0})

# DELETE an item
requests.delete('http://localhost:8000/items/0')

Hurl का उपयोग करना:

# For POST:

POST http://localhost:8000/items/
Content-Type: application/json

{
  "name": "item1",
  "price": 20.0
}

# For GET:

GET http://localhost:8000/items/

#For PATCH:

PATCH http://localhost:8000/items/0
Content-Type: application/json

{
  "name": "item2",
  "price": 30.0
}

# For PUT:

PUT http://localhost:8000/items/0
Content-Type: application/json

{
  "name": "item3",
  "price": 40.0
}

# For DELETE:

DELETE http://localhost:8000/items/0

hurl client.hurl

Swagger Docs at http://localhost:8000/docs पर जाएँ

HTTP वर्ब्स वे तरीके हैं जो किसी दिए गए संसाधन पर की जाने वाली वांछित कार्रवाई को इंगित करते हैं। वे HTTP अनुरोधों के अभिन्न अंग हैं, और यहाँ सबसे सामान्य हैं:

1. GET: GET विधि किसी पुस्तकालय में जाने और लाइब्रेरियन से एक विशिष्ट पुस्तक मांगने के समान है। आप डेटा पढ़ने या डाउनलोड करने का अनुरोध कर रहे हैं, लेकिन कुछ भी बदल नहीं रहे हैं।
2. POST: POST विधि की तुलना एक पत्र लिखने और फिर उसे मेल करने से की जा सकती है। आप एक नया संसाधन बनाने के लिए सर्वर पर डेटा भेज रहे हैं। इसका उपयोग तब किया जाता है जब आप कोई फ़ोटो अपलोड करते हैं या कोई संदेश भेजते हैं।
3. PUT: PUT विधि किसी रिपोर्ट या लेख के ड्राफ्ट को संशोधित करने जैसा है। आप किसी मौजूदा संसाधन को पूरी तरह से अपडेट कर रहे हैं। इसलिए, यदि आप किसी साइट पर अपनी प्रोफ़ाइल जानकारी अपडेट करना चाहते हैं, तो आप संभवतः ऐसा करने के लिए PUT विधि का उपयोग करेंगे।
4. DELETE: DELETE विधि काफी स्पष्ट है - यह कागज के एक टुकड़े को कचरे में फेंकने जैसा है। आप सर्वर से किसी संसाधन को हटाने के लिए कह रहे हैं।
5. PATCH: PATCH किसी टाइपो को ठीक करने या आपके द्वारा लिखे गए निबंध में एक नया वाक्य जोड़ने जैसा है। अनिवार्य रूप से, आप किसी संसाधन को आंशिक रूप से संशोधित कर रहे हैं।

याद रखें कि हालांकि ये उपमाएं बुनियादी अवधारणाओं की व्याख्या करती हैं, HTTP वर्ब्स का वास्तविक कामकाज थोड़ा अधिक जटिल है। ये अंतर सर्वर सेटिंग्स, प्राधिकरण आवश्यकताओं और उस वेब एप्लिकेशन के विशेष कॉन्फ़िगरेशन जैसी चीजों से आते हैं जिसके साथ आप बातचीत कर रहे हैं।

Les verbes HTTP sont des méthodes qui indiquent l'action souhaitée à effectuer sur une ressource donnée. Ils sont essentiels aux requêtes HTTP, et voici les plus courants:

1. GET: La méthode GET est analogue à aller à une bibliothèque et demander à la bibliothécaire un livre spécifique. Vous demandez à lire ou télécharger des données, mais vous ne changez rien.
2. POST: La méthode POST peut être comparée à l'écriture d'une lettre puis à son envoi. Vous envoyez des données au serveur pour créer une nouvelle ressource. Elle est utilisée lorsque vous téléchargez une photo ou envoyez un message.
3. PUT: La méthode PUT est comme réviser un brouillon d'un rapport ou d'un article. Vous mettez à jour une ressource existante dans son intégralité. Donc, si vous vouliez mettre à jour vos informations de profil sur un site, vous utiliseriez probablement la méthode PUT pour le faire.
4. DELETE: La méthode DELETE est assez explicite - c'est comme jeter un morceau de papier à la poubelle. Vous demandez au serveur de supprimer une ressource.
5. PATCH: La méthode PATCH est comme corriger une faute de frappe ou ajouter une nouvelle phrase à un essai que vous avez écrit. Essentiellement, vous modifiez partiellement une ressource.

Rappelez-vous que bien que ces analogies expliquent les concepts de base, le fonctionnement réel des verbes HTTP est un peu plus compliqué. Ces différences proviennent de choses comme les paramètres du serveur, les besoins d'autorisation, et la configuration particulière de l'application web avec laquelle vous interagissez.

HTTP हेडर अनुरोध और प्रतिक्रिया हेडर हैं जिनका उपयोग HTTP अनुरोध में अनुरोध या प्रतिक्रिया के बारे में जानकारी प्रदान करने के लिए किया जा सकता है। HTTP हेडर में होस्ट, यूजर एजेंट, प्राधिकरण, सामग्री प्रकार, सामग्री की लंबाई और कई अन्य के लिए फ़ील्ड शामिल हो सकते हैं। वे उपयोगी हैं क्योंकि वे अनुरोध या प्रतिक्रिया के बारे में मेटाडेटा पास करने का एक संरचित तरीका प्रदान करते हैं।

JSON Web Token (JWT) दो पक्षों के बीच स्थानांतरित किए जाने वाले दावों (claims) का प्रतिनिधित्व करने का एक कॉम्पैक्ट, URL-सुरक्षित तरीका है। इनका उपयोग JSON प्रारूप में प्रमाणीकरण और जानकारी के सुरक्षित प्रसारण में किया जाता है। API के मामले में, JWT का उपयोग पहचान और एक्सेस नियंत्रण की एक विधि के रूप में किया जाता है। वे उपयोगकर्ता की पहचान रख सकते हैं, उपयोगकर्ता एक्सेस नियंत्रण का कुछ रूप प्रदान कर सकते हैं, और संभावित रूप से API ऑपरेशन अनुमतियां भी ले जा सकते हैं।

JWT और HTTP हेडर संबंधित हैं क्योंकि JWT अक्सर HTTP प्राधिकरण हेडर में पारित किया जाता है। इसे आम तौर पर 'Authorization: Bearer {token}' के रूप में प्रेषित किया जाता है। सर्वर तब उपयोगकर्ता को प्रमाणित करने और संसाधनों तक पहुंच को अधिकृत करने के लिए JWT में निहित जानकारी का उपयोग कर सकता है।

संक्षेप में, JWT टोकन पक्षों के बीच जानकारी को सुरक्षित रूप से प्रसारित करने की एक विधि प्रदान करते हैं, जो उपयोगकर्ताओं को प्रमाणित करने और API में कार्यों को अधिकृत करने के तरीके के रूप में कार्य करते हैं। HTTP हेडर के संयोजन में, वे डेटा को प्रसारित करने और एक्सेस करने का एक सुरक्षित तरीका सुनिश्चित करते हैं।

Les en-têtes HTTP sont les en-têtes de requête et de réponse qui peuvent être utilisés dans une requête HTTP pour fournir des informations sur la requête ou la réponse. Les en-têtes HTTP peuvent inclure des champs pour l'hôte, l'agent utilisateur, l'autorisation, le type de contenu, la longueur du contenu, et bien d'autres. Ils sont utiles car ils fournissent un moyen structuré de transmettre des métadonnées sur une requête ou une réponse.

Le jeton Web JSON (JWT) est un moyen compact et sûr pour l'URL de représenter les revendications à transférer entre deux parties. Ils sont utilisés dans l'authentification et la transmission sécurisée des informations au format JSON. Dans le cas des API, les JWT sont utilisés comme moyen d'identification et de contrôle d'accès. Ils peuvent contenir l'identité d'un utilisateur, fournir une forme de contrôle d'accès utilisateur, et peut-être même porter des permissions d'opération d'API.

JWT & les en-têtes HTTP sont liés parce que le JWT est souvent passé dans l'en-tête d'autorisation HTTP. Il est généralement transmis sous la forme 'Authorization: Bearer {token}'. Le serveur peut alors utiliser les informations contenues dans le JWT pour authentifier l'utilisateur et autoriser l'accès aux ressources.

Pour résumer, les jetons JWT fournissent une méthode pour transmettre de manière sécurisée des informations entre les parties, agissant comme un moyen d'authentifier les utilisateurs et d'autoriser les actions dans les API. En combinaison avec les en-têtes HTTP, ils assurent un moyen sûr de transmettre et d'accéder aux données.

Code First और Contract First OpenAPI विनिर्देश का उपयोग करके API डिज़ाइन करने के लिए उपयोग की जाने वाली दो अलग-अलग रणनीतियाँ हैं।

• Code First पद्धति का अर्थ है कि डेवलपर्स कोड लिखना शुरू करते हैं और फिर कोड से OpenAPI विनिर्देश उत्पन्न करते हैं। इस प्रक्रिया में कोड में एंडपॉइंट्स, अनुरोध/प्रतिक्रिया प्रकार आदि का निर्माण शामिल है, जिसे बाद में OpenAPI अनुबंध में बदल दिया जाता है। इस दृष्टिकोण का लाभ यह है कि डेवलपर्स अनुबंध की प्रतीक्षा किए बिना API बनाना शुरू कर सकते हैं। हालाँकि, यह एक कम सुसंगत और अनुमान लगाने में कठिन API सतह का कारण बन सकता है क्योंकि अनुबंध कोड से लिया गया है, और उस कोड की तकनीकीताओं से प्रभावित हो सकता है।
• दूसरी ओर, Contract First पद्धति API अनुबंध को डिज़ाइन करने के साथ शुरू होती है। OpenAPI विनिर्देश (अनुबंध) को पहले सेट किया जाता है, और फिर इस अनुबंध को पूरा करने के लिए कोड विकसित किया जाता है। यह विधि कोडिंग शुरू होने से पहले API कैसा दिखेगा, इसकी स्पष्ट समझ को बढ़ावा देती है, बेहतर क्रॉस-टीम संचार को बढ़ावा देती है और API उपभोक्ताओं को शुरू से ही जरूरतों और आवश्यकताओं पर अपना इनपुट प्रदान करने में सक्षम बनाती है। इसका परिणाम बेहतर डिज़ाइन किया गया और अधिक अनुमानित API हो सकता है। नकारात्मक पक्ष यह है कि API में किसी भी बदलाव के लिए अनुबंध में बदलाव और उन परिवर्तनों के बारे में उपभोक्ताओं को संचार की आवश्यकता होगी।

graph TD;
  A[Start] --> B[Decision Point];
  B --> |Contract First| C[Write API Contract];
  C --> D[Develop Application Code Based on Contract];
  D --> E[End];
  B --> |Code First| F[Write Application Code];
  F --> G[Generate API Contract From Code];
  G --> E;

Code First et Contract First sont deux stratégies différentes utilisées pour concevoir des API en utilisant la spécification OpenAPI.

• La méthodologie Code First signifie que les développeurs commencent par écrire le code et génèrent ensuite la spécification OpenAPI à partir du code. Ce processus comprend la création de points finaux, de types de demande/réponse, etc. dans le code, qui est ensuite transformé en contrat OpenAPI. L'avantage de cette approche est que les développeurs peuvent commencer à construire l'API sans avoir à attendre un contrat. Cependant, cela peut conduire à une surface d'API moins cohérente et plus difficile à prévoir car le contrat est dérivé du code, et peut être influencé par les aspects techniques de ce code.
• D'autre part, la méthodologie Contract First commence par la conception du contrat API. La spécification OpenAPI (le contrat) est établie d'abord, puis le code est développé pour satisfaire ce contrat. Cette méthode favorise une compréhension claire de ce à quoi l'API ressemblera avant que le codage ait commencé, favorisant une meilleure communication entre les équipes et permettant aux consommateurs de l'API de fournir leurs commentaires sur les besoins et les exigences dés le début. Cela pourrait entraîner une API mieux conçue et plus prévisible. L'inconvénient est que tout changement à l'API nécessitera des modifications du contrat et une communication aux consommateurs à propos de ces changements.

graph TD;
  A[Début] --> B[Point de Décision];
  B --> |Contract First| C[Écrire le Contrat API];
  C --> D[Développer le Code de l'Application basé sur le Contrat];
  D --> E[Fin];
  B --> |Code First| F[Écrire le Code de l'Application];
  F --> G[Générer le Contrat API à partir du Code];
  G --> E;

# std
import json
import os

# 3rd party
import openai


def run_completion(prompt, engine="davinci", max_tokens=5):
    openai.api_key = os.environ.get("OPENAI_KEY")
    response = openai.Completion.create(
        engine=engine,
        prompt=prompt,
        max_tokens=max_tokens,
    )
    print(response)
    return response


def run_chat_completion(messages, model="gpt4"):
    openai.api_key = os.environ.get("OPENAI_KEY")
    response = openai.ChatCompletion.create(
        model=model,
        messages=messages,
    )
    print(response)
    return response


if __name__ == "__main__":
    run_completion("Tout juste un test", engine="davinci")
    run_completion("Tout juste un petit coucou", engine="davinci", max_tokens=256)
    run_chat_completion([
        dict(role="user", content="Quel temps fait t'il a Abidjan?")
    ], model="gpt-4-0613")

# std
import json
import os

# 3rd party
import openai


def run_chat_completion(messages, model="gpt4", functions=None, function_call="auto"):
    openai.api_key = os.environ.get("OPENAI_KEY")
    response = openai.ChatCompletion.create(
        model=model,
        messages=messages,
        functions=functions,
        function_call=function_call
    )
    print(response)
    return response


if __name__ == "__main__":
    run_chat_completion(
        [
            dict(role="user", content="Quel temps fait t'il a Abidjan?")
        ],
        model="gpt-4-0613",
        functions=[
            dict(
                name="la_meteo",
                description="Retourne la météo d'une ville",
                parameters=dict(
                    type="object",
                    properties=dict(
                        location=dict(
                            type="string",
                            description="Le nom de la ville, ou le code postal de la ville, ex: Abidjan, ou 00225"
                        ),
                        unit=dict(
                            type="string",
                            enum=["celsius", "fahrenheit"],
                        )
                    ),
                    required=["location"]
                )
            )
        ],
        function_call="auto"
    )