\part{Services Oriented Applications}

Nous avons fait exprès de reprendre l'acronyme d'une \emph{Services Oriented Architecture} pour cette partie.


Dans cette partie: la définition d'une interface REST, la définition d'une interface GraphQL, la gestion des versions d'une API (cf. Build APIs you won't hate) le routage d'URLs.
L'intérêt d'une API est double:

\begin{enumerate}
    \item
        Proposer une ouverture de votre application à d'autres finalités
    \item
        Consommer vos propres interfaces: lorsqu'un soucis se présentera, vous ne l'apprendrez pas par un utilisateur du bout-du-monde, mais parce que vos propres outils vous le rappelerons.
        Vous vous rendez compte également de ce qui ne fonctionne pas, pas correctement, qui manque ou qui doit être amélioré.
        Dans la même veine que tout le reste, donc: maintenance, accessibilité, facilité de déploiement. \footnote{Aussi connu sous le principe de \href{https://en.wikipedia.org/wiki/Eating_your_own_dog_food}{}\textbf{Dogfooding}}, qui consiste à exploiter vous-mêmes vos propres créations.
\end{enumerate}

\begin{quote}
    Don't make me think, or why I switched from JS SPAs to Ruby On Rails
    \url{https://news.ycombinator.com/item?id=30206989\&utm_term=comment}
\end{quote}

On a parcouru les templates et le mode "monolithique de DJango".
Maintenant, on va aborder différentes options:

\begin{enumerate}
    \item
        Le mode "intermédiaire", qui consiste à garder tous les mécanismes internes à Django, mais à ajouter une couche de dynamisme au travers d'une (légère) couche de JavaScript ou via HTMX.
    \item
        Le mode "warrior", qui consiste lui à ajouter une API, d'abord pour vos clients et utilisateurs, mais aussi pour votre propre consommation \footnote{Aussi intitulé "Eat your own dog's food"}
\end{enumerate}