Designfrage zu einem REST-??-Server

[sh17]

Beim Entwurf des REST-API eines Servers bin ich auf folgendes Problem gestoßen, was ich vorher noch gar nicht bedacht hatte:

REST ist ja ressourcenbasiert, also alles ist eine Ressource

/customer/1234
/customer/1234/contact/email
/catalog
/catalog/items

usw.

Jetzt ist es aber auch so, das der Server auch Aufgaben übernehmen soll, die ich in irgend einer Form aktivieren muss.

z.B.
- hier hast Du ein Dokument, schicke das als PDF per E-Mail an Kunde x
- lese diese CSV-Datei in den Artikelstamm ein.

lässt sich so etwas in REST abbilden ohne das Prinzip von REST zu brechen? Ich müsste dann Funktionsaufrufe als Ressource bzw Task betrachten, für jeden Aufruf wird ein neuer Task erstellen, die von einem Task-Handler im Hintergrund abgearbeitet werden.
Aber ist das richtig?

Müsste ich für so etwas auf eine alternative Schnittstelle ausweichen? JSON-RPC, XML-RPC, Websockets?

//Edit
Oder sollten solche Aufgaben von einem (separaten??) REST-Client selbst übernommen werden, sodass er nur mit den Ressourcen hantieren muss. Also keine Funktionalität im Server?

[Rollo62]

Ich denke soweit

Zitat:

/customer/1234/contact/email

sollte man nicht gehen.

Du bekommst unter

Zitat:

/customer/1234

ja eine Tabelle/Record zurück als JSON/XMKL mit allen Spalten.
Das CRUD bezieht sich auf Records (Create/Read/Update/Delete), nicht einzelne Spalten.

Aussedem legst du selber 100% fest was es machen soll.

Rollo

[sh17]

Zitat von Rollo62:

Ich denke soweit

Zitat:

/customer/1234/contact/email

sollte man nicht gehen.

Du bekommst unter

Zitat:

/customer/1234

ja eine Tabelle/Record zurück als JSON/XMKL mit allen Spalten.

Und wenn ich nicht alles vom Kunden möchte, sondern nur seine 5+x E-Mail-Adressen?

[mjustin]

[QUOTE=sh17;1356859
Und wenn ich nicht alles vom Kunden möchte, sondern nur seine 5+x E-Mail-Adressen?[/QUOTE]

Bei REST kann man auch mit Subresourcen arbeiten. Beispiel unter https://github.com/mgonto/restangular

/accounts/123/buildings/456

Da es sehr viele gut dokumentierte REST Frameworks gibt, kann man sich an den "grossen" ganz gut orientieren. Das, was alle ähnlich oder gleich machen, würde ich beherzt als informellen Standard ansehen

[Mavarik]

Zitat von sh17:

Und wenn ich nicht alles vom Kunden möchte, sondern nur seine 5+x E-Mail-Adressen?

Mann muss ja nicht zwingend mit einem URL-Rewrite arbeiten...

http.get('www.myDomain.de/ISAPI/Restserver.dll?Customer=1234&EMAILCount=5'); Ist auch fein...

Mavarik

[sh17]

OK, Danke.

Zu meiner eigentlichen Frage vielleicht nochmal zurück: Sollte man Funktionsaufrufe auf dem Server per REST-API machen dürfen, bzw. ist das in der Spezifikation irgendwo vorgesehen? Oder sollte ich dafür lieber auf RPC etc. ausweichen?

[webcss]

Zitat von sh17:

Jetzt ist es aber auch so, das der Server auch Aufgaben übernehmen soll, die ich in irgend einer Form aktivieren muss.

z.B.
- hier hast Du ein Dokument, schicke das als PDF per E-Mail an Kunde x
- lese diese CSV-Datei in den Artikelstamm ein.

In dem Moment schickst Du ja auch ein entsprechendes Dokument (CSV o.ä.) als UPLOAD an den Server via POST. Einfach mal nach "REST upload" googlen...

[mquadrat]

Bei uns werden Methoden genau wie Ressourcen zur Verfügung gestellt.

Also api/customer/xyz
Und api/machWasTolles

Da geht dann logischerweiser nur get/post. Put oder Delete machen da ja keinen Sinn.

[Mavarik]

Zitat von sh17:

Oder sollte ich dafür lieber auf RPC etc. ausweichen?

emm... Was auch immer Du glaubst was RPC in diesem Zusammenhang bedeutet...

Es sind eigentlich immer RPC-Calls da Server...

Ober meinst Du einen Webservice...?

Ist eigentlich "genau" das Gleiche... (fast)

Ein Webservice hat den Vorteil, dass die Übergabeparameter eigentlich schon vom Design her sofort fertig sind. Jedoch kauft man sich für den Luxus einen größeren Transport overhead (SOAP/XML) ein.

Praktisch kann man genau das gleiche machen, nur das man für REST halt i.d.R. JSON als Transportdatenformat nimmt. (Oder BSON)

Oder wie ich es mache: Eine JSONObject als Header mit einem Stream -> packen -> RSA-crypten -> Base64 und schon kann ich per JSON im Klartext auch ohne SSL Daten zum und vom Server übertragen... Das gleiche nutze ich auch für SOAP...

Und schon kann ich beliebige Daten schicken, ohne jedes mal den Server ändern zu müssen. Wenn Du also eine eMail mit PDF Anhang vom Server aus versenden lassen willst, dann gebe ich einfach das Token(Sendmail with Anhang) where Kunde is Active or Kundennummer > 2823 und die entsprechende PDF Datei an den Server... Und fertig...

Mavarik