REST Osservazioni
Emanuele Di Saverio
mi sono letto un pò di materiale su REST oggi e volevo condividere con
voi alcuni concetti calati nella realtà di QuadraSpace:
1) Uno degli errori nel progettare servizi REST è l'abuso delle POST.
In generale infatti, è raccomandabile l'uso dei 4 metodi HTTP; nello
specifico, la convenzione è utilizzare il POST per ogni funzione che
comporta la creazione di una URI (e quindi di una risorsa) e una PUT
per ogni update di quella risorsa. Il protocollo Qspace si basa solo
su GET e POST; in questa maniera non si permette alle web caches di
lavorare (POST è un metodo non idempotente, mentre PUT si (credo)).
2) in molti casi non è specificato il mapping chiamata - Status code
di risposta. REST infatti utilizza i codici di risposta HTTP come
parte integrante del protocollo, e quindi, per fare un esempio
banalissimo, se chiamo /motes/SENSOR1 e il sensore riferito non
esiste, uno potrebbe ritornare un 404 NotFound.
3) Nella registrazione del mote, cosa torna Quadraspace Server?
Dovrebbe tornare una stringa con l'id assegnato al Mote, nevvero?
Sto mettendo su un inizio dei test di integrazione del Quadraspace
Server: questo ci permette, lavorando in maniera prettamente Agile, di
far seguire alla specifica documentale un immediato insieme di casi di
test :: chiamata + payload ---> risposta.
I test di integrazione tirano su un intero QuadraspaceServer onthe-fly
(grazie alle caratteristiche di embeddability di Glassfish) e testano
le interfacce REST live, con tutto lo stack j2ee appresso.
I test sono solo abbozzati, nel package test.integration, al momento
sto lavorando solo alla registrazione dei Mote; sarebbe carino che
mano mano che si freezano gli xml venissero scritti schemas e test di
integrazione; che ne dite?
Keep on QuadraSpacing
-Emanuele
Stefano Sanna
(ma non stavamo scrivendo in inglese?)
2009/5/5 Emanuele Di Saverio <emanuele....@gmail.com>:
>
> Salve ragazzi,
> mi sono letto un pò di materiale su REST oggi e volevo condividere con
> voi alcuni concetti calati nella realtà di QuadraSpace:
>
> 1) Uno degli errori nel progettare servizi REST è l'abuso delle POST.
> In generale infatti, è raccomandabile l'uso dei 4 metodi HTTP; nello
> specifico, la convenzione è utilizzare il POST per ogni funzione che
> comporta la creazione di una URI (e quindi di una risorsa) e una PUT
> per ogni update di quella risorsa. Il protocollo Qspace si basa solo
> su GET e POST; in questa maniera non si permette alle web caches di
> lavorare (POST è un metodo non idempotente, mentre PUT si (credo)).
Quanto hai scritto e' vero: REST prevede l'utilizzo di (quasi) tutti i
metodi di HTTP per le azioni sugli oggetti. Il motivo per cui ho
limitato a GET e POST la specifica attuale puo' sembrare
stupido/sbagliato ma e' estremamente pratico: i mote basati su JME
(SunSPOT, Sentilla, JSTIX, TINI, nonche' i diffusissimi moduli Siemens
TC65, XT65 e Motorola serie 24) supportano solo GET e POST. In altre
parole, anziche' scrivere una specifica teoricamente corretta ma poi
non adatta alla maggior parte dell'hardware esistente, ho pensato
fosse meglio prendersi qualche liberta' sulla specifica (comunque
minima, mi sembra) ma poterla implementare "senza se e senza ma" su
cio' che abbiamo a disposizione.
> 2) in molti casi non è specificato il mapping chiamata - Status code
> di risposta. REST infatti utilizza i codici di risposta HTTP come
> parte integrante del protocollo, e quindi, per fare un esempio
> banalissimo, se chiamo /motes/SENSOR1 e il sensore riferito non
> esiste, uno potrebbe ritornare un 404 NotFound.
Ora e' implicito ma e' giusto che sia esplicitato, anzi lo includero'
nel prossimo draft. Anche la registrazione di un mote ha il suo
response code (201 - Created).
> 3) Nella registrazione del mote, cosa torna Quadraspace Server?
> Dovrebbe tornare una stringa con l'id assegnato al Mote, nevvero?
Tutta la parte di response e' attualmente "in digestione". :-) Una
possibilita' potrebbe essere questa di restituire il root element del
mote appena registrato con il solo ID:
<mote id="ID_CREATO_DAL_SERVER"/>
> Sto mettendo su un inizio dei test di integrazione del Quadraspace
> Server: questo ci permette, lavorando in maniera prettamente Agile, di
> far seguire alla specifica documentale un immediato insieme di casi di
> test :: chiamata + payload ---> risposta.
Ottimo!
> I test di integrazione tirano su un intero QuadraspaceServer onthe-fly
> (grazie alle caratteristiche di embeddability di Glassfish) e testano
> le interfacce REST live, con tutto lo stack j2ee appresso.
>
> I test sono solo abbozzati, nel package test.integration, al momento
> sto lavorando solo alla registrazione dei Mote; sarebbe carino che
> mano mano che si freezano gli xml venissero scritti schemas e test di
> integrazione; che ne dite?
Antonio si e' offerto di tenere allineati gli schema, sentiamo cosa ci dice lui.
> Keep on QuadraSpacing
QuadraKeeping! :-D :-D :-D
Ciao,
Ste.
--
Stefano Sanna - gerd...@tiscali.it
Personal web site: http://www.gerdavax.it
AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE
Antonio Pintus
>
>> I test di integrazione tirano su un intero QuadraspaceServer onthe-fly
>> (grazie alle caratteristiche di embeddability di Glassfish) e testano
>> le interfacce REST live, con tutto lo stack j2ee appresso.
>>
>> I test sono solo abbozzati, nel package test.integration, al momento
>> sto lavorando solo alla registrazione dei Mote; sarebbe carino che
>> mano mano che si freezano gli xml venissero scritti schemas e test di
>> integrazione; che ne dite?
>>
>
> Antonio si e' offerto di tenere allineati gli schema, sentiamo cosa ci dice lui.
>
>
I think you're doing a good work! :-)
I agree with the adoption of an Agile methodology and to "code a little
- test a little" philosophy :-)
Go ahead with all that test beds and when the XML will be freezed we can
write down, validate and test the schemas together, if you want.
A question: are you using an IDE? Are you using Maven?
Let me know!
Ciao,
Antonio
--
Antonio Pintus
Email: pin...@gmail.com
Home Page: http://www.pintux.it
BLOG: http://jaranto.blogspot.com
My photos: http://www.flickr.com/photos/pintux/
C'e' solo un modo di dimenticare il tempo: impiegarlo.
(Charles Baudelaire)
Hazam
> >: Emanuele
>: Stefano
>
> > Hello guys,
> > I went through some theory about REST today and I'd like to share with you
> > some concepts:
>
> > 1) One of the commons mistake in REST design is abusing POST.
> > In general, it's recommendable the usage of all the 4 HTTP methods;
> > POST is commonly used for functions that will create a URI (and therefore a resource)
> > while a PUT for updates to the resoruce data.
> > QuadraSpace profocols leverages just GETs and POST; in this way, you prevent web caches
> > from doing their work, because GET, PUT and DELETE are idempotent, while POST is not.
>
> what you're saying it's true. REST uses almost all HTTP methods for actions over objects.
> the reason why it's limited to GET and POST it's purely a pragmatic approach: motes based on JME
> (SunSPOT, Sentilla, JSTIX, TINI, and the overly used Siemens
> TC65, XT65 and Motorola series 24 modules) support only GET and POST. In other words,
> instead of writing a specification theorically correct but that will not fit to existing hardware
> I thought that would be better to take some freedom on specification (even if minimal)
> but being able to implement it right away
>
I agree with everything, but the non-REST compiancy it's not minimal,
and will have consequences;
I agree that these consequences are perferable over the difficulties
of implementation client side.
>
> > 2) In many cases it's not specified the mapping call- response status code.
> > REST uses the HTTP response code as part of the protocol, so just to pick an example, if I make a call to /motes/SENSOR1
> > and the sensor does not exists, should return 404/Not found.
>
> Now it is implicit but it will be clearly stated; I will include it in the next draft. the registration too has
> its response code (201 - Created).
>
> > 3) In the mote registration, what does the Quadraspace Server return?
> > Should return a string with the id assigned to the Mote, isn't it?
>
> All responses is actually "under construction" :-) one choice could be returning just the root element of
> the mote just registered with his ID:
>
> <mote id="ID_CREATO_DAL_SERVER"/>
>
> > Right now I'm putting together Sto mettendo su un inizio dei test di integrazione del Quadraspace
> > far seguire alla specifica documentale un immediato insieme di casi di
> > test :: chiamata + payload ---> risposta.
>
>
> > The integration tests start an isntance of the QuadraSpace server on-the-fly
> > and test the live REST interfaces, with all the j2ee stack included.
>
> > the tests are just briefly written, in the package test.integration, at the moment
> > I'm just working on Mote registration; would be a cool think if as the xml are freezes, schemas and integration tests will be written.
> > What do you guys think?
>
> Antonio offered for keeping schemas aligned, let's see what he thinks about that.
Emanuele Di Saverio
> A question: are you using an IDE? Are you using Maven?
>
> Let me know!
Yes, the server project uses Maven and plain JUnit to test even
integration (e.g. no httpunit, selenium or rare beasts).
You can checkout it from http://code.google.com/p/quadraspace-server/,
you should be one the
project admins.
-Emanuele
Emanuele Di Saverio
Antonio Pintus
I was able to successful import the quadraspace-server (using google
code SVN) in NetBeans 6.5.1 (be patient Emanuele but eclipse is not my
favourite IDE ;-) )
and build and test with Maven2 are OK!
Well done Emanuele!
Ciao,
Antonio
Emanuele Di Saverio ha scritto:
Emanuele Di Saverio
this means that the project is truly not IDE dependent, and one could
use theorically IntelliJ or JEdit without sacrificing operativeness.
Antonio Pintus
> this means that the project is truly not IDE dependent, and one could
> use theorically IntelliJ or JEdit without sacrificing operativeness.
>
First problem: I'm not able to commit source to SVN :-( I'm using my
google account...and I don't understand what's happening...
Emanuele Di Saverio
your google account. You can find it at
http://code.google.com/hosting/settings
I think the password is per-user (i mean, not per-project). Maybe that
is the problem?
Antonio Pintus
> your google account. You can find it at
>
> http://code.google.com/hosting/settings
>
> I think the password is per-user (i mean, not per-project). Maybe that
> is the problem?
>
>
Problem solved.
Stefano Sanna (gerdavax)
I have carefully considered the comments you sent and I think that we
have to find a compromise between correctness of the protocol (to be
really RESTful) and the technical feasibility (we can't forget that
many motes use JME runtime). I will share with you all a proposal
about that. The idea behind is:
- design QuadraSpace strictly RESTful (i.e., all methods GET/POST/PUT/
DELETE must be used)
- add extensions to QuadraSpace to let limited HTTP clients (CLDC/MIDP/
IMP) to invoke missing methods (essentially PUT and DELETE)
Stay tuned.
Ciao,
Ste.
On May 5, 12:35 am, Emanuele Di Saverio <emanuele.disave...@gmail.com>
wrote:
Antonio Pintus
>
> - design QuadraSpace strictly RESTful (i.e., all methods GET/POST/PUT/
> DELETE must be used)
> - add extensions to QuadraSpace to let limited HTTP clients (CLDC/MIDP/
> IMP) to invoke missing methods (essentially PUT and DELETE)
>
>
>
Hi,
I think this is a good idea and I'm sure that designing QS to be
strictly RESTful will be our "ROI" in future.
Ciao,
Antonio
Emanuele Di Saverio
I just discovered that Jersey allows to dinamically change incoming
request before resolving to Resources, and does this at a high level
(not at servlet listener level, i mean).
So we can write a clean resource that answers to PUT when it has to,
but having it actually answer to POST too for seriously impaired
devices like JME ones.
It's good when the rightmost choice is also easy to implement :)
I wonder how much work you have to do for doing this in Erlang :)
Bye all
Roberto Ostinelli
case Req:get(method) of
Method when Method =:= ‘PUT’; Method =:= ‘POST’ ->
..haven't been following the whole converstation but basically that
should be it. :)
Emanuele Di Saverio
so you're alive! I hoped you were listening :)
I was talking not only about the switching of the methods (i'm sure
that setting and getting the method it's fairly easy even in Erlang).
I was referring more to the work you have to do to integrate it with
the REST framework, or if you have to build one by yourself.
Thanks for the response anyway!
-Emanuele
Roberto Ostinelli
that far ;)
cheers,
r.