Rest υλοποίηση και http verbs

Από που να ξεκινήσω; Που θα βρω; κ.α. γενικές ερωτήσεις για την δημιουργία μιας ιστοσελίδας.

Συντονιστές: WebDev Moderators, Super-Moderators

Απάντηση
geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από geomagas » 28 Μαρ 2014 14:16

Δεδομένα:
Έστω ότι έχουμε ένα σύστημα που διαχειρίζεται publications.
Χάριν απλοποίησης, κάθε publication έχει ένα id, ένα publication date και "άπειρα" translations (μπορεί και κανένα!).
Από την άλλη, ένα translation έχει προφανώς το κείμενό του, τον κωδικό του publication του οποίου είναι μετάφραση και τον κωδικό της γλώσσας (el,en,jp κλπ).

Σε μία RESTful υλοποίηση, η πρόσβαση στο / με GET και Accept: application/json θα έδινε κάτι σαν:

Κώδικας: Επιλογή όλων

200 OK
{
  "appname": "Publications",
  "links":
    [
      {"rel": "self", "href": "http://pubs.domain.tld/"}
      {"rel": "list", "href": "http://pubs.domain.tld/pub/"}
    ]
}
Στη συνέχεια, GET /pub Accept: application/json:

Κώδικας: Επιλογή όλων

200 OK
{
  "items": 
    [
      {
        "id": "ABC",
        "pubdate": "2014-02-23",
        "langs": ["en", "it"],
        "links": [{"rel": "self", "href": "http://pubs.domain.tld/pub/ABC/"}]
      },
      {
        "id": "XYZ",
        "pubdate": "2012-05-07",
        "langs": ["gr", "es", "de"],
        "links": [{"rel": "self", "href": "http://pubs.domain.tld/pub/XYZ/"}]
      }
      .........
    ]
  "links":
    [
      {"rel": "self", "href": "http://pubs.domain.tld/pub/"}
      {"rel": "search", "href": "http://pubs.domain.tld/pub/search"}
    ]
}
(από τα παραπάνω έχω απαλείψει πολλά πράγματα, διότι το μόνο που θέλω να δείξω είναι η δομή των urls)

Προϋπόθεση είναι ότι, κατά το GET του πχ /pub/XYZ/ θα ελέγχεται ο Accept-Language για να αποφασιστεί η γλώσσα για την οποία ενδιαφέρεται ο client. Αλλά δεν υπάρχει request header που να ταιριάζει (τυπικά) στα υπόλοιπα "ρήματα".

Προφανώς η εισαγωγή νέων publications γίνεται με POST στο /pub/, και αντίστοιχα η επεξεργασία/διαγραφή με PUT/DELETE στο /pub/{id}/.

---
Το θέμα αφορά τις μεταφράσεις. Όπως το βλέπω, υπάρχουν δύο τρόποι υλοποίησης:

Α. Κάθε publication είναι ένα collection από μεταφράσεις.
Με αυτό το σκεπτικό, αν θέλουμε να προσθέσουμε την Αγγλική μετάφραση του XYZ θα κάναμε POST στο /pub/XYZ/ μία πλειάδα πχ

Κώδικας: Επιλογή όλων

{'lang": "en", "content": "The big brown fox jumped over the lazy dog"}
Αυτό θα δημιουργήσει ένα νέο resource με url /pub/XYZ/en που θα "παίζει" για τα PUT/DELETE. Επιπλέον, είναι προφανές τι θα παίρνουμε με GET, ενώ κατά την πρόσβαση στο /pub/XYZ με Accept-Language: en (βλ. παραπάνω) θα παίρνουμε 301 στο /pub/XYZ/en.

Β. Τα publications είναι απλά resources και όχι collections.
Τότε θα πρέπει να θεωρήσουμε ότι οι μεταφράσεις είναι απλά "πεδία" του ίδιου resource. Σωστά;
Κατά τη δημιουργία μίας νέας μετάφρασης, κανένα νέο url δεν δημιουργείται και, για το publication XYZ, όλα γίνονται μέσω του /pub/XYZ.
Ενώ με το GET δεν υπάρχει ζήτημα, όλες οι άλλες λειτουργίες θα πρέπει να γίνουν με update, και μάλιστα κατά προτίμηση partial! Αυτό υπονοεί τη χρήση PATCH. Ή κάνω λάθος;

---
Θα ήθελα σχόλια σχετικά με το RESTful-ness των παραπάνω. Βλέπετε κάτι που δεν "συμφωνεί με τα standards";
Επίσης, ποια υλοποίηση θα διαλέγατε για τις μεταφράσεις και γιατί;

Άβαταρ μέλους
cpulse
Script Master
Δημοσιεύσεις: 1527
Εγγραφή: 21 Μαρ 2006 19:30
Τοποθεσία: Αθήνα village
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από cpulse » 28 Μαρ 2014 15:43

Όλο αυτό που φτιάχνεις θα λειτουργεί μόνο σαν API; Ή ταυτόχρονα βγάζει και κανονική ιστοσελίδα;

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από geomagas » 28 Μαρ 2014 16:28

Για να πω την αλήθεια, δεν φτιάχνω κάτι συγκεκριμένο.
Για πολύ καιρό μελετούσα το REST όποτε έβρισκα το χρόνο, εντελώς θεωρητικά.
Τώρα που είπα να ασχοληθώ πιο "εντατικά", και πριν ακόμα κάνω πραγματικά πειράματα, νοιώθω ότι προέτρεξα λίγο :oops: και είπα να ζητήσω σχολιασμό για τη θεωρία μου.

Πάντως, αυτό που ρωτάς δεν νομίζω να έχει σχέση με το RESTful μοντέλο, καθώς υποτίθεται ότι η ίδια εφαρμογή ανταποκρίνεται αναλόγως με το media type που ζητείται (HATEOAS).
Βέβαια τα παραδείγματα που βάζω είναι σε json, αλλά χωρίς βλάβη της γενικότητας κάποιο resource θα μπορούσε το ίδιο άνετα να ανταποκριθεί σε html αν αυτό του είχε ζητηθεί.

alou
Script Master
Δημοσιεύσεις: 1374
Εγγραφή: 24 Αύγ 2007 19:52
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από alou » 28 Μαρ 2014 18:07

Δεν "τόχω" και πολύ αλλά πρακτικά, θα τα θεωρούσα nested resources με ένα url structure κάπως έτσι:

Κώδικας: Επιλογή όλων

GET /publications
GET /publications/create                           
POST /publications
GET /publications/{id}
GET /publications/{id}/edit
PUT /publications/{id}
DELETE /publications/{id}
GET /languages
GET /languages/create
POST /languages
GET /languages/{id}
GET /languages/{id}/edit
PUT /languages/{id}
DELETE /languages/{id}
GET /publications/{id}/languages
GET /publications/{id}/languages/create
POST /publications/{id}/languages
GET /publications/{id}/languages/{id}
GET /publications/{id}/languages/{id}/edit
PUT /publications/{id}/languages/{id}
DELETE /publications/{id}/languages/{id}
Αν πάμε σε υλοποίηση με συγκεκριμένες προδιαγραφές, πιθανώς να προκύψουν πολλά θέματα αλλά δεν νομίζω πως υπάρχει περίπτωση να μη λύνεται με μια τέτοια δομή.

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από geomagas » 28 Μαρ 2014 19:26

alou έγραψε:Δεν "τόχω" και πολύ...
Χεχε! Το'χεις-δεν το'χεις, έτρεφα μια ελπίδα ότι θα συμμετείχες! :)
alou έγραψε:Αν πάμε σε υλοποίηση με συγκεκριμένες προδιαγραφές, πιθανώς να προκύψουν πολλά θέματα αλλά δεν νομίζω πως υπάρχει περίπτωση να μη λύνεται με μια τέτοια δομή.
Σίγουρα λύνεται, δεν υπάρχει αμφιβολία. Και φαντάζομαι ότι υπάρχουν κι άλλοι τρόποι δόμησης των url που θα έκαναν τη δουλειά.
Αλλά δεν είναι το θέμα "να το λύσουμε με κάποιο τρόπο". Όπως προείπα, αυτό ήταν αφορμή να βρω ένα παράδειγμα για να ξεκαθαρίσω τι είναι RESTful και τι όχι.

Από αυτή τη σκοπιά λοιπόν:

1) Αυτά τα δύο:

Κώδικας: Επιλογή όλων

GET /publications/create
POST /publications
..δεν είναι ισοδύναμα; (ισχύει και για άλλα ζευγάρια)

2) Αυτό:

Κώδικας: Επιλογή όλων

GET /publications/create
...δεν υπονοεί RPC; Εννοώ, δεν είναι resource αλλά action, σωστά;

(ας βγάλουμε "εκτός" τη δομή /languages/* για να μην μπλέξουμε, κι ας θεωρήσουμε ότι όλες οι γλώσσες είναι πάντα γνωστές και διαθέσιμες)

Άβαταρ μέλους
cpulse
Script Master
Δημοσιεύσεις: 1527
Εγγραφή: 21 Μαρ 2006 19:30
Τοποθεσία: Αθήνα village
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από cpulse » 28 Μαρ 2014 21:05

Άμα πας να φτιάξεις API δεν χρειάζεσαι όμορφα URL. Όλα όσα λες μπορούν να γίνουν με κλασσικές μεταβλητές.

Ούτε το header Accept-Language έχει πολύ χρησιμότητα σε APIs. Αυτό έχει χρησιμότητα σε browsers που πληροφορούν τον server. Στα APIs η κλήση δεν γίνεται από τον browser, αλλά από κάποιο client ειδικά φτιαγμένο για το API σου. Εγώ θα το έβαζα κι αυτό κάπου στις μεταβλητές.

Ακόμα και τα HTTP verbs είναι ψιλοαδιάφορα. Αν θες να είσαι κοντά στο ιδανικό χρησιμοποίησε τα, αλλά μπορείς να κάνεις σχεδόν τα πάντα μόνο με GET και POST. Στην πράξη κάποιοι proxies κάνουν cache τα GET requests, άρα όταν θες να κάνεις αλλαγές ή να ζητάς δυναμικό περιεχόμενο προτίμησε ο,τιδήποτε εκτός του GET.

Επίσης, μη το σκέφτεσαι μόνο από την πλευρά του server. Φτιάξε κι ένα υποδειγματικό client για να δεις πως θα κάνεις τη ζωή των άλλων προγραμματιστών εύκολη.

Λαστ μπατ νοτ λίστ, υπάρχει μόδα τελευταία με το json format, αλλά το XML είναι πιο ευέλικτο. Δημιουργεί λιγότερους πονοκέφαλους στους προγραμματιστές που θα φτιάξουν τα clients, σε περίπτωση που κάνεις κάποιο upgrade στο API και αλλάξεις τα formats. Διάβασε εδώ περισσότερα.

Αν τώρα το πας για απλή ιστοσελίδα, η γνώμη μου είναι να κρατήσεις το τμήμα του URL για την γλώσσα στην αρχή. Έτσι πάντα το υπόλοιπο URL θα είναι το ίδιο σε όλες τις γλώσσες. πχ.
http://www.example.com/el/path/to/page

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από geomagas » 28 Μαρ 2014 21:27

Μα είπα ήδη ότι δεν πάω για κάτι συγκεκριμένο.
Είπα - επίσης ήδη - ότι δεν ενδιαφέρομαι για best bractices ή να διαχωρίσω browsers από άλλους clients ή ποιο format είναι πιο ευέλικτο.
Ούτε ο στόχος μου είναι να κάνω τη ζωή άλλων προγραμματιστών πιο εύκολη -- αν θέλω να τους την κάνω πιο εύκολη, θα τους παρέχω κι έναν έτοιμο client σε τουλάχιστον μία γλώσσα, και άφθονο documentation με πολλά παραδείγματα.

Στην παρούσα φάση ενδιαφέρομαι να κατανοήσω μία μεθοδολογία μοντελοποίησης: Το REST.
Το οποίο έχει συγκεκριμένους κανόνες και προϋποθέσεις (αλλά και ελευθερίες!).

Αυτά που λες σίγουρα θα βοηθούσαν αν ήθελα να πάρω προτάσεις για την ανάπτυξη ενός site ή ενός api.
Αλλά αυτό που χρειάζομαι αυτή τη στιγμή είναι αντικειμενικές και αιτιολογημένες απόψεις για το τι είναι RESTful και τι όχι.

Άβαταρ μέλους
cpulse
Script Master
Δημοσιεύσεις: 1527
Εγγραφή: 21 Μαρ 2006 19:30
Τοποθεσία: Αθήνα village
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από cpulse » 28 Μαρ 2014 21:50

Ξεκίνα από αυτό σαν να ήταν συγκεκριμένο.
Η εμπειρία σου θα σου δείξει πολλά περισσότερα από τις απόψεις οποιουδήποτε :)

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από geomagas » 28 Μαρ 2014 22:08

Εννοείς να το υλοποιήσω στην πράξη;

alou
Script Master
Δημοσιεύσεις: 1374
Εγγραφή: 24 Αύγ 2007 19:52
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από alou » 31 Μαρ 2014 10:25

geomagas έγραψε:
alou έγραψε:Δεν "τόχω" και πολύ...

1) Αυτά τα δύο:

Κώδικας: Επιλογή όλων

GET /publications/create
POST /publications
..δεν είναι ισοδύναμα; (ισχύει και για άλλα ζευγάρια)
Όπως σου είπα, δεν το έχω και πολύ.
Όπως το βλέπω το GET /publications/create θα έφερνε ότι στοιχείο θες να πάρεις πριν στείλεις το νέο item (πχ τα names των values που θα στείλεις στο POST) και το POST θα το αποθήκευε.
geomagas έγραψε:
2) Αυτό:

Κώδικας: Επιλογή όλων

GET /publications/create
...δεν υπονοεί RPC; Εννοώ, δεν είναι resource αλλά action, σωστά;
Δεν καταλαβαίνω γιατί το λες και βασικά δεν στέκομαι τόσο στο θεωρητικό όσο στο πρακτικό κομμάτι. Αν η επικοινωνία χρειάζεται ένα σετ από στοιχεία πριν δημιουργήσει κάτι καινούργιο (ή επεξεργαστεί κάτι που υπάρχει) πως θα το έκανες?

Η διαφορά με το RPC - με όσα λίγα ξέρω - είναι ότι μια λογική RPC σου δίνει πολύ περισσότερες δυνατότητες για να παραμετροποιήσεις το request και μεθόδους που θα κάνουν πολύ περισσότερα πράγματα, από ένα rest api πχ getPublicationsRPC.php?start=20&end=130&lang=en&active=true ενω σε ένα rest api έχεις περισσότερες ευκολίες στο design αλλα και περισσότερους περιορισμούς στο τι μπορείς να κάνεις. Επίσης, το REST είναι stateless ενώ το rpc μπορεί να μην είναι, πολύ σημαντικό και κριτήριο ίσως για να επιλέξεις τι θα κάνεις.

Βάλε και τα θέματα post / get caching , proxies και δε συμμαζεύεται που είπε και ο cpulse και έχεις να μελετάς για μήνες τον καλύτερο τρόπο σε μια σύνθετη εφαρμογή.

Σαν το καλύτερο σημείο εκκίνησης μάλλον θα θεωρούσα αυτό που είπε ο cpulse:
Επίσης, μη το σκέφτεσαι μόνο από την πλευρά του server. Φτιάξε κι ένα υποδειγματικό client για να δεις πως θα κάνεις τη ζωή των άλλων προγραμματιστών εύκολη.

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από geomagas » 31 Μαρ 2014 12:48

alou έγραψε:
geomagas έγραψε: 1) Αυτά τα δύο:

Κώδικας: Επιλογή όλων

GET /publications/create
POST /publications
..δεν είναι ισοδύναμα; (ισχύει και για άλλα ζευγάρια)
Όπως σου είπα, δεν το έχω και πολύ.
Καλά, απ' ότι θα κατάλαβες, ούτε εγώ "το' χω". Όλο αυτό γίνεται για να προσπαθήσω να το "αποκτήσω"... :)
alou έγραψε:Όπως το βλέπω το GET /publications/create θα έφερνε ότι στοιχείο θες να πάρεις πριν στείλεις το νέο item (πχ τα names των values που θα στείλεις στο POST) και το POST θα το αποθήκευε.
Χμμμμ... Εγώ νόμιζα ότι ήταν η ίδια λειτουργία αλλά με GET (οι τιμές στο query string).
Δηλαδή σαν να λέμε, αν το request ζητούσε html σαν media type, θα παίρναμε μία σελίδα με μία φόρμα, έτσι;
Έτσι που το θέτεις είναι ενδιαφέρουσα άποψη. Αν και δεν το έχω ξανασυναντήσει στα παραδείγματα που διαβάζω.
Άσε με να το "επεξεργαστώ" λίγο...
alou έγραψε:
geomagas έγραψε:
2) Αυτό:

Κώδικας: Επιλογή όλων

GET /publications/create
...δεν υπονοεί RPC; Εννοώ, δεν είναι resource αλλά action, σωστά;
Δεν καταλαβαίνω γιατί το λες και βασικά δεν στέκομαι τόσο στο θεωρητικό όσο στο πρακτικό κομμάτι. Αν η επικοινωνία χρειάζεται ένα σετ από στοιχεία πριν δημιουργήσει κάτι καινούργιο (ή επεξεργαστεί κάτι που υπάρχει) πως θα το έκανες?
Καλά, αφού διευκρίνισες το παραπάνω, αυτή η απορία δεν στέκει πλεον.
Αν τα δύο παραπάνω ήταν ισοδύναμα, τότε το url αυτό δεν θα υποδήλωνε resource αλλά action (ή function, ή verb ή όπως αλλιώς θέλει κάποιος να το πει).
Με την αυστηρή θεωρία του rest, δεν θα ήταν καν valid url (αφού r=resource).
alou έγραψε:Η διαφορά με το RPC - με όσα λίγα ξέρω - είναι ότι μια λογική RPC σου δίνει πολύ περισσότερες δυνατότητες για να παραμετροποιήσεις το request και μεθόδους που θα κάνουν πολύ περισσότερα πράγματα, από ένα rest api πχ getPublicationsRPC.php?start=20&end=130&lang=en&active=true ενω σε ένα rest api έχεις περισσότερες ευκολίες στο design αλλα και περισσότερους περιορισμούς στο τι μπορείς να κάνεις.
Έτσι είναι σε γενικές γραμμές.
Με rpc η λειτουργία είτε υπονοείται από το url (όπως στο παράδειγμά σου) είτε ενσωματώνεται στο body (πχ SOAP), οπότε θεωρητικά μπορείς να κάνεις τα πάντα με GET/POST.
Στο rest, κάθε url αφορά αποκλειστικά resource, και τα ήδη υπάρχοντα http verbs χρησιμοποιούνται για να κάνεις ενέργειες πάνω του.
Έχει κι άλλες προϋποθέσεις βέβαια, αλλά αυτά αφορούν τη διαφοροποίηση με το rpc.
alou έγραψε:Επίσης, το REST είναι stateless ενώ το rpc μπορεί να μην είναι, πολύ σημαντικό και κριτήριο ίσως για να επιλέξεις τι θα κάνεις.
Είναι stateless, όπως θεωρητικά "θα πρέπει να είναι" το http εν γένει. Όμως αυτό είναι λίγο παρεξηγημένο/διφορούμενο.
Πολλοί πιστεύουν ότι stateless σημαίνει ανυπαρξία state. Σε αυτά που διαβάζω όμως, όποιος αναφέρεται σε αυτό συνήθως λέει ότι "το application state είναι ευθύνη του client" και όχι "δεν πρέπει να υπάρχει application state" (πράγμα το οποίο θεωρώ ότι θα ήταν και ανέφικτο!).
alou έγραψε:Βάλε και τα θέματα post / get caching , proxies και δε συμμαζεύεται που είπε και ο cpulse και έχεις να μελετάς για μήνες τον καλύτερο τρόπο σε μια σύνθετη εφαρμογή.
Σίγουρα το caching είναι πού βασική παράμετρος για το rest. Παίζει πολύ σημαντικότερο ρόλο από ότι σε άλλες υλοποιήσεις.
Αλλά είπα να μην τα πιάσω όλα μαζί. Άσε να καταλάβουμε τη θεωρία πρώτα, και για τα υπόλοιπα βλέπουμε! :)
Αλλά έχω μια υποψία ότι δεν θα είναι και τόσο χρονοβόρο. Συνήθως η τυποποίηση χρησιμεύει ακριβώς στο να επισπεύδει το σχεδιασμό και την υλοποίηση... Όταν θα έχω γίνει "rest guru" θα μπορώ να πω με σιγουριά! :)
alou έγραψε:Σαν το καλύτερο σημείο εκκίνησης μάλλον θα θεωρούσα αυτό που είπε ο cpulse:
Επίσης, μη το σκέφτεσαι μόνο από την πλευρά του server. Φτιάξε κι ένα υποδειγματικό client για να δεις πως θα κάνεις τη ζωή των άλλων προγραμματιστών εύκολη.
Θα το κάνω κι αυτό κάποια στιγμή. Ελπίζω τώρα κοντά, για να έχουμε κάτι χειροπιαστό να συζητάμε (με όποιον ενδιαφέρεται!)

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

Rest υλοποίηση και http verbs

Δημοσίευση από geomagas » 10 Απρ 2014 14:56

Είχα πάρει φόρα με το θέμα, αλλά λόγω ασθένειας δεν το έχω προχωρήσει όσο θα ήθελα... :-?

Τέλος πάντων, βάζω προς το παρόν το link (rest.geomagas.gr) για όποιον ενδιαφέρεται να συμμετέχει στην "αναζήτηση".
Δεν δουλεύουν και πολλά πράγματα. Έχω αρχίσει από τους users και δουλεύουν μόνο GETs (και κάποια OPTIONS) ενώ προς το παρόν υποστηρίζεται text/html και application/json (σε λίγο και application/xml). Φυσικά, ούτε λόγος για caching ...yet.

Υπάρχει και ένας υποτυπώδης client σε javascript, που λειτουργεί σαν "spider" -- χρησιμοποιεί τα links από το json representation για να διατρέξει (ανακαλύψει) την όλη δομή (στο explorer).

Απάντηση

Επιστροφή στο “Γενικές ερωτήσεις κατασκευής ιστοσελίδων”

Μέλη σε σύνδεση

Μέλη σε αυτήν τη Δ. Συζήτηση: Δεν υπάρχουν εγγεγραμμένα μέλη και 1 επισκέπτης