On Wed, Oct 3, 2012 at 6:53 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>
>> Yes. So that makes Pipes API for java a wrapper around
>> HttpRestAdapter.
>> Also from this a gather that Pipes API does not use
>> GET/POST/PUT/DELETE naming scheme, but it is closely aligned with it
>> nonetheless.
>
> Sorry, my bad here. The way I understand is actually that Pipes API is more of a
persistence API - layer 2 API if you wish, not GET/POST/PUT/DELETE (layer 1 type) API.
Well, the pipe is just an abstraction layer for 'a' server connection (type).
It was designed to hide the 'technical' details (e.g. http/rest), so
yes. more of persistence instead of directly REST (GET/POST....).
=> A pipe can be used for different connection types (Transport
layers), for instance websocket..
For instance calling 'save' for instance on a pipe
('myOtherPipe.save()') would issue something like
'websocket.send()'...
For READ, it's a bit different (difficult), since it's more 'event
driven'....
At least in iOS (thanks to the blocks), it's not too hard; I guess the
same is true for the JS layer as well (e.g. callbacks)
-M
NOTE: No design was done for that (websocket) so far... just saying.
-Matthias
>
>>
>> >
>> > -Matthias
>> >
>> >
>> > >
>> > >
>> > >>
>> > >> >
>> > >> >> The above picture 'models' URIs for this UML
diagram:
>> > >> >>
http://www.infoq.com/resource/articles/rest-introduction/en/resources/fig...
>> > >> >>
>> > >> >
>> > >> > Actually I understand this as two layers where figure1 layer
>> > >> > API,
>> > >> > uses figure2 layer API.
>> > >> > That's the business interface layer that delegates to
>> > >> > HttpRestAdapter, the two layer approach. In our case
>> > >> > persistence
>> > >> > view with operations like findById ...
>> > >> >
>> > >>
>> > >> yes figure1 is the 'business' API, and figure2 shows how
these
>> > >> 'methods' map to the URIs...
>> > >>
>> > >>
>> > >>
>> > >> >
>> > >> >> (Taken from this article =>
>> > >> >>
http://www.infoq.com/articles/rest-introduction)
>> > >> >>
>> > >> >> However the figure2.jpg shows as well, that there maybe
cases
>> > >> >> where a
>> > >> >> DELETE on /tasks (or '/customers/{id}/orders') and
a POST on
>> > >> >> /tasks/{id} (or '/orders/{id}') can make sense.
>> > >> >>
>> > >> >> => We need to cover that too...
>> > >> >> If I recall correctly those two 'corner cases' are
also not
>> > >> >> covered
>> > >> >> by
>> > >> >> the JavaScript library.
>> > >> >>
>> > >> >>
>> > >> >> > - I wouldn't eat exceptions, and return null even
in a
>> > >> >> > not-yet-real
>> > >> >> > exception handling :)
>> > >> >> >
(
https://github.com/danielpassos/aerogear-android/blob/new-pipeline/src/ma...)
>> > >> >> >
>> > >> >> > Really, either don't catch it, or if you do catch
it,
>> > >> >> > rethrow
>> > >> >> > it
>> > >> >> > as
>> > >> >> > is, or wrap into another - normally RuntimeException
is
>> > >> >> > perfectly
>> > >> >> > fine, so you don't pollute your API with throws
>> > >> >> > declarations.
>> > >> >>
>> > >> >>
>> > >> >> +1 on this comment - but he added a TODO already ;)
>> > >> >>
>> > >> >
>> > >> > That's why I wrote 'even in a not-yet-real exception
handling'
>> > >> > i.e.
>> > >> > don't _ever_ do it like that :)
>> > >> >
>> > >> >>
>> > >> >> >
>> > >> >> > - I would use IllegalArgumentException here:
>> > >> >> >
https://github.com/danielpassos/aerogear-android/blob/new-pipeline/src/ma...
>> > >> >> >
>> > >> >> > It's more appropriate, as it's a standard
pattern for this
>> > >> >> > kind
>> > >> >> > of
>> > >> >> > use-case. By convention UnsupportedOperationException
is
>> > >> >> > used
>> > >> >> > for
>> > >> >> > empty methods where interface contract is not fully
>> > >> >> > supported.
>> > >> >> >
>> > >> >>
>> > >> >> +1
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> > - We have to do something about this
"getId"
>> > >> >> >
(
https://github.com/danielpassos/aerogear-android/blob/new-pipeline/src/ma...)
>> > >> >> >
>> > >> >> > One idea is to have an annotation - @Id. But scanning
for
>> > >> >> > annotations needs to be done at init time or lazily
on
>> > >> >> > first
>> > >> >> > use
>> > >> >> > ...
>> > >> >> > So maybe we could have an abstract base class with
abstract
>> > >> >> > method
>> > >> >> > getId() that every data object has to extend, and
>> > >> >> > implement.
>> > >> >> > A
>> > >> >> > simpler, and more robust solution actually, as
compiler
>> > >> >> > will
>> > >> >> > enforce it so there is no way for not providing one,
as
>> > >> >> > could
>> > >> >> > happen with forgotten or wrong placement of @Id
annotation
>> > >> >> > for
>> > >> >> > example.
>> > >> >> >
>> > >> >>
>> > >> >> I think the problem here is that not every object has an
>> > >> >> 'id',
>> > >> >> the
>> > >> >> field could be name 'recordId' - In JavaScript
this is
>> > >> >> configurable.
>> > >> >> iOS has a TODO here...
>> > >> >>
>> > >> >
>> > >> > That's interesting. Can you give some examples?
>> > >> >
>> > >> >
>> > >> >>
>> > >> >> -Matthias
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> >
>> > >> >> > That's about it for now ... :)
>> > >> >> >
>> > >> >> > - marko
>> > >> >> >
>> > >> >> >
>> > >> >> > ----- Original Message -----
>> > >> >> >>
>> > >> >> >>
>> > >> >> >> Hi guys
>> > >> >> >>
>> > >> >> >>
>> > >> >> >> I did some changes in the android library based
on iOS
>> > >> >> >> stuff,
>> > >> >> >> it's
>> > >> >> >> closer to the pipeline adapter implementation. I
would
>> > >> >> >> appreciate
>> > >> >> >> feedback and review.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
https://github.com/aerogear/aerogear-android/pull/1
>> > >> >> >>
https://github.com/aerogear/aerogear-android-todo/pull/1
>> > >> >> >>
>> > >> >> >>
>> > >> >> >> Thanks,
>> > >> >> >> Passos
>> > >> >> >> _______________________________________________
>> > >> >> >> aerogear-dev mailing list
>> > >> >> >> aerogear-dev(a)lists.jboss.org
>> > >> >> >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >> >> >>
>> > >> >> > _______________________________________________
>> > >> >> > aerogear-dev mailing list
>> > >> >> > aerogear-dev(a)lists.jboss.org
>> > >> >> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> --
>> > >> >> Matthias Wessendorf
>> > >> >>
>> > >> >> blog:
http://matthiaswessendorf.wordpress.com/
>> > >> >> sessions:
http://www.slideshare.net/mwessendorf
>> > >> >> twitter:
http://twitter.com/mwessendorf
>> > >> >>
>> > >> >> _______________________________________________
>> > >> >> aerogear-dev mailing list
>> > >> >> aerogear-dev(a)lists.jboss.org
>> > >> >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >> >>
>> > >> > _______________________________________________
>> > >> > aerogear-dev mailing list
>> > >> > aerogear-dev(a)lists.jboss.org
>> > >> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Matthias Wessendorf
>> > >>
>> > >> blog:
http://matthiaswessendorf.wordpress.com/
>> > >> sessions:
http://www.slideshare.net/mwessendorf
>> > >> twitter:
http://twitter.com/mwessendorf
>> > >>
>> > >> _______________________________________________
>> > >> aerogear-dev mailing list
>> > >> aerogear-dev(a)lists.jboss.org
>> > >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >>
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev(a)lists.jboss.org
>> > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog:
http://matthiaswessendorf.wordpress.com/
>> > sessions:
http://www.slideshare.net/mwessendorf
>> > twitter:
http://twitter.com/mwessendorf
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev(a)lists.jboss.org
>> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf