Ergebnis 1 bis 6 von 6

Thema: REST und warum ich es wohl nie verwenden werde

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    REST sehe ich auf einer Ebene mit dem klassischen Semantic Web: Eine nette Idee, aber weltfremd. Wenn wir nicht die hergebrachte Browserkultur hätte, wäre REST sicher ein interessanter Ansatz; im heutigen Internet aber ist es nur eine weitere Spielerei, die in einer sehr kleinen Zahl von Fällen tatsächlich einen Nutzen hat.

    Immerhin einen Teil hat REST richtig hingekriegt: Kurze URIs. URIs sind heutzutage einfach zu lang und enthalten oft auch etwas sinnlos erscheinende Informationen (so beinhaltet der URI, über den ich gerade zur Postmaske gekommen bin, den amüsanten Substring "newreply.php?do=newreply").

    Vielleicht sollte man HTTP HTTP sein lassen und sich lieber auf URIs im Format protokoll://host/typ/id/action einigen. Damit bleiben die URIs auch kurz, Standardaktionen wären programmatisch einfach zu erreichen (sofern man sich auf ein paar Standardverben einigt) und wir müssen nicht über Nacht das gesamte Internet auf eine neue Technologie mit fragwürdigem Mehrwert umstellen.


    Zum Thema "URI": Der URI. Es sei denn, wir sind PC und sagen "der/die universelle Ressourcen-IdentifikatorIn".

  2. #2
    Zitat Zitat von Jesus_666 Beitrag anzeigen
    Vielleicht sollte man HTTP HTTP sein lassen und sich lieber auf URIs im Format protokoll://host/typ/id/action einigen. Damit bleiben die URIs auch kurz, Standardaktionen wären programmatisch einfach zu erreichen (sofern man sich auf ein paar Standardverben einigt) und wir müssen nicht über Nacht das gesamte Internet auf eine neue Technologie mit fragwürdigem Mehrwert umstellen.
    Die Defaulteinstellung von Rails ist protokoll://host/typ/action/id, aber ich werde wohl auf protokoll://host/typ/id/action/parameter umsteigen.

  3. #3
    URIs wie 'newreply.php?do=newreply' sind ein - ich nenn es mal einfach so - "Relikt" aus vergangenen Zeiten, wo PHP4 noch weiter verbreitet war als PHP5 (ähhh... also heute noch. srly.). Mit PHP5 und den erweiterten OOP möglichkeiten kahmen dann auch die MVC Frameworks, welche sich an Struts oder Rais orientierten und welche für mich der größte Quantensprung in der PHP Entwicklung darstellen. Aus gründen der SEO unterstützen die meisten dann auch diese tollen kuzen URIs (bsp Zend Framework [/Modul]/Controller/Action[/paramN/valN]. Mittlerweile scheinen die Crawler aber nachgezogen zu haben und die kuzen URIs sind noch da, weil sie schlicht awesome sind.

    Zu REST: In meiner direkten Umgebung setze ich REST in mehreren Projekten ein. Gerade für schnelle Use-Cases oder Prototypen komm ich nicht mehr drum rum. Ein schönes Beispiel ist ein QR-Code (2d Barcodes) Modul, welches ich für einen Adserver geschrieben habe. Wird dieses Modul über die URL angesprochen, liefert es eine XML mit einer XSL. Passiert das im Browser wird eine schöne HTML Seite geformt - passiert das über des Anzeigensystem (MFC) kann dieses einfach die XML weiter verarbeiten und die XSL ignorieren. REST ist für mich nicht mehr oder weniger als Daten über die URL anzufordern

  4. #4
    Für mich hört es sich an, als wäre REST in deinem Fall... ein stinknormaler HTTP-Query. XSL(T) ist an sich von REST unabhängig; der einzigartige Teil bei REST ist ja, daß der URI nicht mehr repräsentiert, was man mit der Ressource tun möchte.

  5. #5
    Mehr ist es ja auch nicht - nur das man ggf mehr PUT und DELETE verwendet, was wiederum auch in HTTP spezifizeirt ist - aber vom standart Browseranwender dann wohl doch eher selten verwendet wird. Jo klar ist XSLT ne eigene Sache, aber in verbindung mir REST ergeben sich tolle Anwendungsfälle.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •