Est-ce qu'être RESTful important? [fermé]

Question

Je travaille sur une application basée sur le Web qui utilise un JSON via HTTP API basée pour communiquer entre le serveur et le client. L'objectif étant que plusieurs clients peuvent être développés avec des objectifs différents (client Web en ligne, client de bureau en ligne, ou tiers) créé en utilisant les mêmes données en ligne à partager à travers ce service Web.

En ce moment, la communication entre le client et le serveur est envoyé uniquement via POST grâce à un système qui fonctionne bien. Je lis un peu d'informations sur REST et être RESTful avec HTTP en utilisant PUT, GET, POST et DELETE. Je pourrais séparer mon API dans ces différentes catégories, mais cela signifie plus de code et quelques modifications à l'API.

Ma question est: quelle est l'importance pour une API basée sur HTTP être RESTful? Est-ce une recommandation, une option ou une nécessité proche?

Merci d'avance.

Answer 1

En tant que die-hard RESTafarian Je dirais que l'utilisation HTTP (le protocole REST en question) dans toute son étendue. Pourquoi? Eh bien, je vais vous montrer deux extraits d'un échange de courriels, j'ai eu hier avec un bon ami à moi qui est sérieusement intelligent (et utilisé pour être professeur d'informatique, des conférences encore, lance encore le cul partout où il va);

  

Hier je suis passé un important   étape importante pour mon mappodrhom
  Application: Je peux maintenant lancer   calculs de base de longue durée
  dans un bassin de travailleurs. Quand ils ont fini,   les travailleurs republier leurs résultats   directement dans les ressources REST.   Ce qui déclenche plus de fond   le traitement, le tout contrôlé par un   graphe de dépendance.

     

Et l'aspect intéressant est que   ce RESTful est
semi-finition   en fait indépendante de mon   application particulière. Mais je suis
  actuellement trop fatigué pour complètement   saisir les conséquences: -)

Les conséquences en question sont énormes (il est un cadre de repos avec beaucoup de petits tas et des événements et des services et des applications, toutes avec leur propre découvrable URIs, tous avec la même interface unifiée), et en termes d'extensibilité et d'évolutivité, il est tout simplement inégalée dans sa simplicité. Si votre application est une petite chose Dinky qui ne sera jamais voyager endroits ou rencontrer des poussins chauds, oui peut-être vous n'avez pas besoin. Mais alors, je l'ai dit la même chose, et tout d'un coup me suis retrouvé dans un train à Paris avec une jolie fille qui est un espion secret pour les Russes, et bien, une chose a conduit à une autre ...

Voici ma réponse, avec quelques-uns de mes propres expériences;

  

Je pense que cela puisse paraître (pardonnez mon français)   f *** ing génial! Je rencontre   des choses similaires avec mes propres trucs de repos,   où parce que la couche intermédiaire est si   mince et transparente, je peux   étendre les choses comme je les ai besoin   sans se soucier trop de la   Infrastructure. Il est une telle liberté,   une telle chose cool kick-ass que mon   Le cerveau est exploser au sujet, et   curiosité inquiétant de savoir pourquoi plus ne sont pas   le faire?

En bref, faire REST seulement à mi-chemin est comme ne pas faire vraiment du tout. Vous êtes juste déplacer vos trucs sur un pipeline différent, manquant sur une API simplifiée dans un état machine, le découplage semantics- et la mise en œuvre au cœur, en collaboration avec les principes qui ont construit le net (et donc je dirais que vous » ve a des idées plutôt éprouvées derrière vous), l'interface unifiée, et ayant URIs dans le cadre de votre modélisation.

Je sais qu'il est populaire de dire que vous pouvez choisir, que c'est tout juste options. Ce n'est pas. REST n'a de sens en utilisant pleinement, mais pour vous convaincre de réellement étirer votre cerveau un peu plus loin et faire quelque chose d'intelligent, je ne peux oser vous couper à travers le FUD (qu'il est tout au sujet de RPC, que GET et POST nécessaire, vous n'avez pas besoin tout, ce qui équivaut à JSON, SOAP et d'autres acabit, etc.), et être plus intelligent sur la façon dont vous faites des applications. Oui, je vous mets au défi tous!

Answer 2

Sauf si vous allez profiter de hypermédia alors je ne serais pas la peine d'essayer de se conformer aux contraintes de repos. Hypermédia est la pièce du puzzle qui rend le système plus grand que la somme de ses parties.

Vous êtes libre de choisir lequel des contraintes de repos que vous voulez respecter dans votre architecture, juste noter que pour être en mesure d'appeler le résultat final RESTful, la seule contrainte facultative est « code téléchargement ».

Answer 3

Il est une option parmi plusieurs pour exposer une application web en tant que service Web avec une API bien définie. D'autres options incluent:

1. Non API - L'application n'a aucun moyen réel pour être utilisé comme composant dans d'autres systèmes distribués
2. SOAP - Un format XML pour définir les appels d'API à distance
3. JSON - Un format compact pour l'échange d'informations qui peuvent être construit sur pour créer un format API personnalisé (ou utilisé pour construire un système REST si vous voulez)
4. Beaucoup d'autres formes d'appels de procédure à distance et des supports d'échange d'informations.

REST a un joli idéal derrière, mais cela ne signifie pas que vous devez fournir une API REST pour votre application. Si le gain ne vaut pas l'effort supplémentaire, ne prend pas la peine.

Answer 4

Il est une recommandation. Je suis heureux que vous n'êtes pas allé dans la façon dont RESTful vous devez aller en car il y a quelque chose appelé Salut-Repos et Lo-REST. Vous pouvez obtenir plus d'informations de googler. Certains vétérans de l'industrie que je connais font à ce sujet, pas beaucoup de soins mais je ne trouve en restant aussi proche HTML et http vous aider à long terme, et simplifie beaucoup de choses.

Answer 5

Je dirais que c'est un agréable d'avoir, mais pas un must. Dans mon expérience en ajoutant cette architecture augmente la portée et la complexité du projet, mais il ajoute un degré d'élégance à l'ensemble. Je dirais que si vous avez le temps et le budget du projet, allez-y, sinon, ne vous inquiétez pas.

Answer 6

L'un (des nombreux) choses à considérer avec le service API est la facilité avec laquelle ils peuvent être consommés par votre utilisateur final. REST gagne une présence d'outillage très forte.

De loin le plus grand groupe de dev là-bas est le groupe dev .NET et avec ADO.NET pour les services (Astoria) consommant REST LINQ est très simple et très élégant.