On Tue, May 6, 2014 at 6:18 PM, Christos Vasilakis <cvasilak(a)gmail.com>wrote:
Hi Joshua,
my belief is that for PUT, DELETE ops the client should go against
/contacts/{id} URI
+1 , The best practice with REST is that an existing resource
representation includes the id in the URI.
Anyone else have a different view of it ?
Thanks,
Christos
On May 1, 2014, at 5:32 PM, joshuaw <jowilson(a)redhat.com> wrote:
Christos,
To answer a) since the Contact is being passed in, it is not necessary to
also pass in the ID. For PUT all the information needs to be passed back
for the update. While the DELETE only needs the ID, the whole contact is
being sent.
I am open to discussing this if you think there is something wrong with
the design.
Joshua
*From:* Christos Vasilakis [via aerogear-dev] [mailto:[hidden email]]
*Sent:* Thursday, May 01, 2014 7:27 AM
*To:* joshuaw
*Subject:* Re: [aerogear-dev] contacts-mobile-basic quick start
Hi everyone,
have started working on the iOS native client of the contacts quick start
app. Based on edewit branch[1] (which creates a contact on signup of a
user) have created an initial version of the iOS client and you can find it
here [2], together with a screencast showcasing the app in action [3].
Some comments observed during writing of the application which would like
your feedback:
a) for PUT, DELETE operations noticed that the jax-rs backend expects the
id of the Contact to be present in the body of the request. Not sure why
this was chosen instead of @Path(“id”) resulting against /contacts/{id} ?
b) currently roles are used to distinguish between who is able to
create/update/delete contact. When a user signs up (and contact is
created), by default the user is _not_ able to apply any CRUD operations
apart from viewing (any operation results in unauthorised error). If we
agree on this behaviour, would like to know how can I determine the role of
the user (in order to update the UI accordingly, eg. disabling add,edit UI
elements). Looking at the json response upon login of the user, couldn’t
determine a “key” that specifies the role (apart from an “admin” key which
stayed the same regardless of the type of the user).
Thanks,
Christos
[1]
https://github.com/edewit/jboss-wfk-quickstarts/tree/push_and_secured
[2]
https://github.com/cvasilak/aerogear-push-quickstarts/tree/ios
[3]
https://vimeo.com/93471554
On Apr 23, 2014, at 5:43 PM, Erik Jan de Wit <[hidden email]> wrote:
> Right, that makes sense, so let’s not join them. The alternate thing to
do is to create a contact on sign up, because if you want to receive push
notifications at least you should be in the list of contacts. We will still
need to change the sign up page a little as we need a phone number and a
birth date as well in order to create a contact.
>
> On 23 Apr,2014, at 16:26 , Burr Sutter <[hidden email]> wrote:
>
>> These are not strongly held opinions
>>
>> One reason to keep Users & Contacts separate is...because that is
normal for the average enterprise app - your have employees (users) and
customers (contacts) - employees/users have different roles/privileges from
customers.
>>
>> The reason they are separated in the secured (PL) version of
contacts-mobile-basic is because it simply evolved that way - contacts came
first - users/roles added after the fact. Ideally we would not modify the
original too much as it allows a nice learning progression - start with the
original contacts-mobile-basic, then upgrade to
contacts-mobile-basic-secured, then upgrade to
contacts-mobile-basic-secured-cordova (names just made up).
>>
>>
>> On Apr 23, 2014, at 10:16 AM, Sébastien Blanc <[hidden email]> wrote:
>>
>>> Sure !
>>> Be sure to check this with Joshua as he drives the backend bits
>>> Sébi
>>>
>>> Envoyé de mon iPhone
>>>
>>>> Le 23 avr. 2014 à 15:56, Erik Jan de Wit <[hidden email]> a écrit
:
>>>>
>>>> Hi,
>>>>
>>>> How about merging the User model and the Contact into one entity?
Seems like they have a lot in common, do we really need 2?
>>>>
>>>> Cheers,
>>>> Erik Jan
>>>>
>>>>> On 23 Apr,2014, at 14:34 , Sébastien Blanc <[hidden email]>
wrote:
>>>>>
>>>>> We should be using the email as alias and the email should also be
used as login when registering in the secured part. A registration should
also trigger the creation of that user / contact in the application.
>>>>> Author can be left empty By the client and filled by the backend .
https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_sec... must
stay because the receiver must know who sends the message.
>>>>>
>>>>> Envoyé de mon iPhone
>>>>>
>>>>>> Le 23 avr. 2014 à 13:35, Erik Jan de Wit <[hidden email]>
a écrit
:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was working on the aerogear-push-quickstarts for Cordova and
was
wondering what to put for the alias on registration. The version that is
there now has users that logs in and contacts that are fetched. What seems
to be missing is that everybody gets all contacts instead of just mine
(maybe that is fine), but users that sign up for the app are not contacts.
So when I want to send a message to a specific mobile user they are not in
my list and there is no way to have to define an alias to send to.
>>>>>>
>>>>>> Also the interface for sending push notifications includes a
author. I think it would be better if we remove this and let the service
put in the logged in user. That way you can’t pretend to send a message
like someone else.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Cheers,
>>>>>> Erik Jan
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> [hidden email]
>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> [hidden email]
>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email]
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
------------------------------
*If you reply to this email, your message will be added to the discussion
below:*
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-mobile-ba...
To start a new topic under aerogear-dev, email [hidden email]
To unsubscribe from aerogear-dev, click here.
NAML<http://aerogear-dev.1069024.n5.nabble.com/template/NamlServlet.jt...
------------------------------
View this message in context: RE: [aerogear-dev] contacts-mobile-basic
quick
start<http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-contacts-...
Sent from the aerogear-dev mailing list
archive<http://aerogear-dev.1069024.n5.nabble.com/>at
Nabble.com.
_______________________________________________
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