Même si j'offre des alternatives à mettre et supprimer (c.f. "Low repose"), comment puis-je fournir une validation de formulaire conviviale pour les utilisateurs qui accèdent à mon service Web depuis le navigateur, tout en exposant toujours des uRis reposantes? Le problème de validation de formulaire (décrit ci-dessous) est mon quandaire actuel, mais la question plus large que je veux poser est la suivante: si je baisse le chemin d'essayer de fournir à la fois une interface publique reposante et un non-javascript Interface HTML, va-t-il rendre la vie plus facile ou plus difficile? Jouent-ils ensemble du tout?
En théorie, il devrait être simplement une question de variation du format de sortie. Une machine peut interroger l'URL "/ personnes" et obtenir une liste de personnes dans XML. Un utilisateur humain peut pointer leur navigateur à la même URL et obtenir une jolie réponse HTML à la place. (J'utilise le EXEMPLES URL des microformats WIKI , qui semblent assez raisonnables). < / p>
Créer une nouvelle ressource personne est effectué avec une demande postale à l'URL "/ personnes". Pour y parvenir, l'utilisateur humain peut d'abord visiter "/ personnes / nouveau", qui renvoie un formulaire HTML statique pour la création de la ressource. Le formulaire a la méthode = poste et action = "/ personnes". Cela fonctionnera bien si l'entrée de l'utilisateur est valide, mais si nous validons du côté serveur et découvrez une erreur? La chose amicale serait de renvoyer la forme, peuplée avec les données que l'utilisateur vient d'entrer, plus un message d'erreur afin de pouvoir résoudre le problème et à soumettre à nouveau. Mais nous ne pouvons pas retourner cette sortie directement à partir d'un poste à "/ personnes" ou casse notre système d'URL, et si nous redirigeons l'utilisateur sur le formulaire "/ personnes / nouveau", il n'y a aucun moyen de signaler l'erreur et repeuplez la forme (sauf si nous stockons les données à l'état de la session, ce qui serait encore moins reposant).
avec JavaScript, les choses seraient beaucoup plus faciles. Faites simplement le message en arrière-plan et s'il échoue, affichez l'erreur en haut du formulaire. Mais je souhaite que l'application dégradra gracieusement lorsque le support JavaScript n'est pas disponible. Pour le moment, je suis amené à conclure qu'une application Web non triviale ne peut pas implémenter une interface HTML sans JavaScript, et Utiliser un schéma d'URL retenue conventionnel (tel que celui décrit sur le wiki des microformats). Si je me trompe, dites-moi s'il vous plaît!
Questions connexes sur le débordement de la pile (ni dont la validation de la forme):
4 Réponses :
Pourquoi ne pas utiliser Ajax pour effectuer le travail du côté du client et si JavaScript est désactivé, concevez le HTML afin que le poste conventionnel fonctionnerait.
Hmm, je pourrais l'obtenir à travail , probablement en ayant le formulaire HTML post sur "/ personnes / nouveau". Mais cela signifie utiliser des URL non réparatrices, ce qui me conduit à nouveau à la conclusion que les formes HTML vanille ne sont tout simplement pas compatibles avec la philosophie de repos.
@Todd "URL reposantes" est un concept inexistant. Le repos spécifie rien des uris sauf qu'ils doivent être opaques.
J'ai posté une question similaire sur la manière dont les formes HTML s'intègrent au repos. Vérifiez-le
Imo L'interface de formulaire HTML est distincte du repos. Le formulaire devrait pouvoir être construit à partir des connaissances de l'API de repos, pas d'interagir avec l'API.
Vous pourriez avoir le formulaire HTML poster directement sur / personnes / nouveau. Si la validation échoue, rérendez le formulaire d'édition avec les informations appropriées. Si cela réussit, transférez l'utilisateur à la nouvelle URL. Cela serait compatible avec l'architecture de repos comme je le comprends.
Je t'ai vu commentaire à Monis Iqbal, et je dois admettre que je ne sais pas ce que vous entendez par "URL non réparatrices". La seule chose que l'architecture de repos demande à une URL est qu'elle soit opaque et qu'elle soit uniquement jumelée à une ressource. Le repos ne se soucie pas de ce à quoi on dirait, ce qui y est, comment des barres obliques ou utilisées, combien sont utilisées, ou quoi que ce soit comme ça. La conception visible de l'URL est à vous et que le reste n'a pas de roulement.
Par "non-repos", je voulais dire qu'il ne convient pas aux suggestions décrites sur http // microformats.org / wiki / repos / URL, qui recommande qu'une nouvelle ressource soit créée par un poste à "/ personnes". Je vois cependant de votre point - mon interface peut aussi facilement être: obtenir "/ personnes / nouveau" = formulaire vide, post "/ personnes / nouveau" = créer une ressource.
Oh ouais, ces recommandations. Je me souviens quand ils les ont inventés. Remarquez comment il est indiqué au sommet que Ruby sur des rails utilisées; éditer et; nouveau? C'était mon idée stupide, car éditer, et la nouvelle ne me semblait pas semblable comme moi séparée ressources de / personnes, juste une manière différente de rendre la même ressource. J'ai donc trouvé que le point-virgule pourrait être utilisé pour indiquer que, au lieu de la relation infantile / implique. ; Broke Safari cependant, si flltt.
En tout état de cause, vous pouvez également le modeler afin que les postes / personnes rendent votre "nouveau" formulaire, mais avec des alertes sur ce qui s'est mal passé.
De cette façon, vous suivez les recommandations et votre API peut être utilisée par ces choses qu'il est indiquée compatible avec ce formulaire.
En rétrospective, j'aimerais que je voulais suggérer. au lieu. Ensuite, vous auriez toujours la distinction, mais vous ne finiriez pas de briser sa safari.
regarde bien pour moi. Je suppose que c'est potentiellement confus, car je me réfère à beaucoup de symboles sans les citer.
Ah désolé. @Todd Fyi Le repos n'a rien à voir avec une utilisation appropriée des verbes http, et il n'y a pas de "URL reposantes" malgré ce qu'il dit dans votre lien. Le reste ne se soucie pas de quoi ressemblent vos uris.
Merci pour les réponses. Ils ont un peu libé mes préoccupations, et donc en réponse à ma propre question, je voudrais proposer une alternative ensemble de Consulions de l'URL reposantes qui embrasse les deux méthodes (obtenir et post) du monde non Ajax, au lieu d'essayer de travailler autour d'eux.
Edit: Comme les commentateurs ont souligné, ces "conventions" ne devraient pas faire partie de l'API reposante elle-même. D'autre part, les conventions internes sont utiles car elles rendent la mise en œuvre du côté serveur plus cohérente et donc plus facile pour les développeurs à comprendre et à entretenir. Les clients reposants devraient toutefois traiter les URL comme opaque et les obtenir toujours comme des hyperliens, jamais en construisant eux-mêmes des URL.
get / personnes Il y a un motif ici: Montez sur une ressource, par ex. "/ personnes / 1", renvoie l'enregistrement lui-même. Obtenez sur la ressource + l'opération renvoie un formulaire HTML, par exemple. "/ personnes / 1 / Modifier". Le poste sur la ressource + l'opération exécute en fait l'opération.
Peut-être que ce n'est pas aussi élégant que d'utiliser des verbes HTTP supplémentaires (mettre et supprimer), mais ces URL doivent bien fonctionner avec les formulaires HTML vanille. Ils devraient également être assez explicites à un utilisateur humain ... Je suis un croyant dans l'idée que "l'URL fait partie de l'interface utilisateur" pour les utilisateurs accédant au serveur Web via un navigateur.
P.s. Permettez-moi d'expliquer comment je ferais les suppressions. La vue "/ personnes / 1" aura un lien vers "/ personnes / 1 / Supprimer", avec un gestionnaire JavaScript OnClick. Avec JavaScript activé, le clic est intercepté et une zone de confirmation présentée à l'utilisateur. S'ils confirment la suppression, un message est envoyé, supprimant immédiatement l'enregistrement. Mais si JavaScript est désactivé, cliquez sur le lien qui envoie une demande d'obtention, ce qui renvoie un formulaire de confirmation de suppression du serveur, et que le formulaire envoie le message à effectuer la suppression. Ainsi, JavaScript améliore l'expérience utilisateur (réponse plus rapide), mais sans cela, le site Web se dégrade gracieusement.
Renvoyer une liste de tous les enregistrements
Get / Personnes / Nouveau
renvoyer un formulaire pour ajouter un nouvel enregistrement de
Post / Personnes / Nouveau
Créer un nouvel enregistrement de
(Pour un client HTML, renvoyez le formulaire à nouveau si l'entrée est invalide, sinon redirige à la nouvelle ressource)
GET / GENS / 1
retourner le premier record
Obtenir / gouttes / 1 / Modifier
renvoyer un formulaire pour éditer le premier record
Post / Personnes / 1 / Modifier
mettre à jour le premier record
GET / GENS / 1 / Supprimer
renvoyer un formulaire pour supprimer le record de
(Peut être simplement une confirmation - êtes-vous sûr de vouloir supprimer?)
Post / Personnes / 1 / Supprimer
Supprimer l'enregistrement
Voulez-vous vraiment créer une interface reposante? Si tel est le cas, arrêtez d'essayer de créer des conventions d'URL. Au-delà de cela, je ne vois rien ici que vous ne pouvez pas déjà faire avec ATMPLUB. Pourquoi réinventer la roue?
Définir les conventions URI dans le cadre de votre API signifie que votre API est RPC. URI doit être découvertable via Hypertext, en commençant par un seul uri d'entrée-point. Voir: ROY.GBIV.COM/untangled/2008/ Reste-Apis-be-be-hypertexte-driver en
Merci, je me souviendrai de ça. Dans ce cas, les URL iE énumérés ne font pas partie de l'API, simplement une décision de mise en œuvre ... auquel un client reposant ne devrait porter aucune attention. Ils arrivent juste à être assez pratiques à mettre en œuvre (dans Struts 2, au moins, ce qui est ce cadre que j'utilise), et également compatible avec les formulaires HTML vanille. [Réponse modifiée pour clarifier cela.]
@Todd c'est raisonnable, il n'y a rien faux avec de jolis Uris. Assurez-vous simplement qu'ils sont découvrez par hypertexte.
Pourquoi voulez-vous créer une seconde "API" en utilisant XML?
Votre HTML contient les données dont votre utilisateur doit voir. HTML est relativement facile à analyser. L'attribut de classe peut être utilisé pour ajouter une sémantique en tant que microformats. Votre HTML contient des formulaires et des liens pour pouvoir accéder à toutes les fonctionnalités de votre application.
Pourquoi créeriez-vous une autre interface qui offre une application / XML gratuite entièrement sémantique qui ne contiendra probablement aucun lien hypermédia afin que vous ayez maintenant une URL de code difficile dans votre client, créant un couplage désagréable?
Si vous pouvez obtenir votre application fonctionnant à l'aide de HTML dans un navigateur Web sans avoir à stocker l'état de la session, vous avez déjà une API reposante. Ne vous tuez pas en essayant de concevoir un tas d'URL qui correspond à l'idée d'une norme de quelqu'un.
Voici un citation de Roy Fielding,
Une API de repos ne doit pas définir fixe Noms de ressources ou hiérarchies
Je sais que cela vole face à probablement presque tous les mêmes exemples de repos que vous avez vu, mais c'est parce qu'ils sont tous faux. Je sais que je commence à ressembler à un zélote religieux, mais cela me tue de voir des personnes qui se battent pour concevoir des API reposantes lorsqu'elles commencent complètement le mauvais pied.
Écoutez Breton quand il dit que «le reste ne se fiche pas de quoi ressemble [l'URL]» et @wahnfrieden sera bientôt suivi pour vous dire la même chose. Cette page de microformats est horrible conseil pour quelqu'un qui tente de se reposer. Je ne dis pas que ce sont des conseils horribles pour une personne qui crée une autre sorte d'API HTTP, tout simplement pas de repos.
Merci pour le lien informatif. En fait, je n'ai pas besoin de l'interface XML immédiatement, mais je le vois comme un bon test d'une architecture d'application propre (spécifiquement, séparation de la présentation de la logique des entreprises). Si l'application peut émettre XML en plus de HTML, avec un minimum d'effort pour le développeur, il devrait être facile d'émettre tout format de sortie requis à l'avenir.
HTML est assez facile dans un sous-ensemble de XML de toute façon.
@Todd, cela revient à mon avis que des interfaces reposantes sont destinées à exposer le contenu à un "agent utilisateur", pas de données commerciales aux applications de consommation. C'est ce que sont les services Web. Je vois des interfaces reposantes et des services Web en résolvant deux problèmes différents.
@Todd Il n'y a pas de "faible repos" - juste pour que vous sachiez, le repos permet de contourner les normes d'un protocole, tant qu'il est nécessaire en raison des implémentations de clients incorrectes, c'est-à-dire HTML4 uniquement en faveur de la poste / get.