You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Cassie <do...@apache.org> on 2008/06/19 00:57:14 UTC
The perfect social service interfaces
Hey guys -
So I was just starting to add a messaging service to the java code and I saw
that the new java service interfaces still need a lot of cleanup. I also
noticed how similar they were to one another because of how structured the
rest calls have been making everything. So... I started thinking about a
generics based interface that could work for all of the different types of
objects we currently have and could hopefully extend to photos, movies, etc.
Anybody want to give me some quick feedback on a simple service like this:
// T is the type of model object that this service deals with. (I know,
crappy name, feel free to suggest a better one)
// T = Activity, Person, Message or Map<String, String> (ie Data)
public interface ItemService<T> {
public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
GroupId groupId, String appId, Set<String> fields, SortOrder sort,
SortDirection direction, FilterType filter,
int first, int max, SecurityToken token);
public ResponseItem<T> getItem(UserId userId, GroupId groupId, String
appId,
Set<String> fields, String itemId, SecurityToken token);
public ResponseItem<T> deleteItem(UserId userId, GroupId groupId, String
appId,
String itemId, SecurityToken token);
public ResponseItem createItem(UserId personId, GroupId groupId, String
appId,
Set<String> fields, T item, SecurityToken token);
// None of the services have this right now... but it maps to "put" in
rest. Will we ever actually use this call?
public ResponseItem updateItem(UserId personId, GroupId groupId, String
appId,
Set<String> fields, T item, SecurityToken token);
}
Now Data doesn't -quite- fit with this model because it doesn't return a
List<T> it should return a Map<String, T> but yeah.. we can special case
that somehow for now or eventually be more standard and get rid of it. We
could also compose userId, groupId and appId into an object to remove some
of this overly large param list clutter or something...
Alright, so, "horrible idea I've lost my mind" or "so, so idea I don't think
it'll work long term" or "sure, go and refactor it".
Thanks.
- Cassie
Re: The perfect social service interfaces
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Cassie <do...@apache.org> writes:
>public interface ItemService<T> {
> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
[...]
> public ResponseItem<T> getItem(UserId userId, GroupId groupId, String
[...]
> public ResponseItem<T> deleteItem(UserId userId, GroupId groupId, String
[...]
> public ResponseItem createItem(UserId personId, GroupId groupId, String
[...]
> public ResponseItem updateItem(UserId personId, GroupId groupId, String
[...]
>}
Actually, for appData, GET and PUT (getItem and updateItem) are better
than "getItem/createItem". We are using a REST style interface to
access our backend and noticed that POSTing items doesn't work too
well, because appdata keys are actually only updated (and spring into
existence when not there).
Ciao
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
"Professor Peach in the library with the lead piping!" -- Donna
Re: The perfect social service interfaces
Posted by Cassie <do...@apache.org>.
On Thu, Jun 19, 2008 at 1:55 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> "sure, go and refactor it". makes a lot of sense to me as I can see other
> areas of the spec emerging which might need new service api's
>
> although I agree with Kevin's comment about the consumer knowing what the
> item is....
>
> 2 questions.
>
> Are you also going to have interfaces for the model, as IMHO having a
> service API that forces the implementor to use concrete classes owned by the
> consumer of that API means the API is semi concrete (did that make sense
> :))..... it would also make it easier to use a wider range of
> implementation strategies.
Oh geeze. I am a bad person for not doing this for so long, I know. Okay, so
I didn't apply your patch directly because it had too many inconsistent
style thingys that I knew would be faster to fix if I just got my ide to
pull the interfaces out super quickly. I should have just done this so long
ago. Anyway, I'm gonna check this in in round 30 min.
>
>
> and
>
> I trust that you are intending to do a default impl before fixing the API,
> just to see how it feels in the wild.
>
> Ian
>
>
>
>
> On 18 Jun 2008, at 23:57, Cassie wrote:
>
> Hey guys -
>>
>> So I was just starting to add a messaging service to the java code and I
>> saw
>> that the new java service interfaces still need a lot of cleanup. I also
>> noticed how similar they were to one another because of how structured the
>> rest calls have been making everything. So... I started thinking about a
>> generics based interface that could work for all of the different types of
>> objects we currently have and could hopefully extend to photos, movies,
>> etc.
>>
>>
>> Anybody want to give me some quick feedback on a simple service like this:
>>
>> // T is the type of model object that this service deals with. (I know,
>> crappy name, feel free to suggest a better one)
>> // T = Activity, Person, Message or Map<String, String> (ie Data)
>>
>> public interface ItemService<T> {
>>
>> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
>> GroupId groupId, String appId, Set<String> fields, SortOrder sort,
>> SortDirection direction, FilterType filter,
>> int first, int max, SecurityToken token);
>>
>> public ResponseItem<T> getItem(UserId userId, GroupId groupId, String
>> appId,
>> Set<String> fields, String itemId, SecurityToken token);
>>
>> public ResponseItem<T> deleteItem(UserId userId, GroupId groupId, String
>> appId,
>> String itemId, SecurityToken token);
>>
>> public ResponseItem createItem(UserId personId, GroupId groupId, String
>> appId,
>> Set<String> fields, T item, SecurityToken token);
>>
>> // None of the services have this right now... but it maps to "put" in
>> rest. Will we ever actually use this call?
>> public ResponseItem updateItem(UserId personId, GroupId groupId, String
>> appId,
>> Set<String> fields, T item, SecurityToken token);
>>
>> }
>>
>> Now Data doesn't -quite- fit with this model because it doesn't return a
>> List<T> it should return a Map<String, T> but yeah.. we can special case
>> that somehow for now or eventually be more standard and get rid of it. We
>> could also compose userId, groupId and appId into an object to remove some
>> of this overly large param list clutter or something...
>>
>>
>> Alright, so, "horrible idea I've lost my mind" or "so, so idea I don't
>> think
>> it'll work long term" or "sure, go and refactor it".
>> Thanks.
>>
>> - Cassie
>>
>
>
Re: The perfect social service interfaces
Posted by Ian Boston <ie...@tfd.co.uk>.
"sure, go and refactor it". makes a lot of sense to me as I can see
other areas of the spec emerging which might need new service api's
although I agree with Kevin's comment about the consumer knowing what
the item is....
2 questions.
Are you also going to have interfaces for the model, as IMHO having a
service API that forces the implementor to use concrete classes owned
by the consumer of that API means the API is semi concrete (did that
make sense :))..... it would also make it easier to use a wider
range of implementation strategies.
and
I trust that you are intending to do a default impl before fixing the
API, just to see how it feels in the wild.
Ian
On 18 Jun 2008, at 23:57, Cassie wrote:
> Hey guys -
>
> So I was just starting to add a messaging service to the java code
> and I saw
> that the new java service interfaces still need a lot of cleanup. I
> also
> noticed how similar they were to one another because of how
> structured the
> rest calls have been making everything. So... I started thinking
> about a
> generics based interface that could work for all of the different
> types of
> objects we currently have and could hopefully extend to photos,
> movies, etc.
>
>
> Anybody want to give me some quick feedback on a simple service
> like this:
>
> // T is the type of model object that this service deals with. (I
> know,
> crappy name, feel free to suggest a better one)
> // T = Activity, Person, Message or Map<String, String> (ie Data)
>
> public interface ItemService<T> {
>
> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
> GroupId groupId, String appId, Set<String> fields, SortOrder
> sort,
> SortDirection direction, FilterType filter,
> int first, int max, SecurityToken token);
>
> public ResponseItem<T> getItem(UserId userId, GroupId groupId,
> String
> appId,
> Set<String> fields, String itemId, SecurityToken token);
>
> public ResponseItem<T> deleteItem(UserId userId, GroupId groupId,
> String
> appId,
> String itemId, SecurityToken token);
>
> public ResponseItem createItem(UserId personId, GroupId groupId,
> String
> appId,
> Set<String> fields, T item, SecurityToken token);
>
> // None of the services have this right now... but it maps to
> "put" in
> rest. Will we ever actually use this call?
> public ResponseItem updateItem(UserId personId, GroupId groupId,
> String
> appId,
> Set<String> fields, T item, SecurityToken token);
>
> }
>
> Now Data doesn't -quite- fit with this model because it doesn't
> return a
> List<T> it should return a Map<String, T> but yeah.. we can special
> case
> that somehow for now or eventually be more standard and get rid of
> it. We
> could also compose userId, groupId and appId into an object to
> remove some
> of this overly large param list clutter or something...
>
>
> Alright, so, "horrible idea I've lost my mind" or "so, so idea I
> don't think
> it'll work long term" or "sure, go and refactor it".
> Thanks.
>
> - Cassie
Re: The perfect social service interfaces
Posted by Cassie <do...@google.com>.
On Wed, Jun 25, 2008 at 9:47 AM, Henning P. Schmiedehausen <hps@intermeta.de
> wrote:
> Cassie <do...@apache.org> writes:
>
> > public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
> > GroupId groupId, String appId, Set<String> fields, SortOrder sort,
> > SortDirection direction, FilterType filter,
> > int first, int max, SecurityToken token);
>
> Why is "appid" needed? And especially, why is it in the method signature?
appId would be needed because with the restful spec you can request data or
activities for a specific app which does not necessarily have to be the
authorized app.
>
> Some background: We are using a shindig install, where the secure
> token is completely opaque and all information inside the token is
> never visible to the java side. App id is a part of this
> information. So we hand the token to our "backend", which also created
> the token in the first place and knows how to decode it and rely on
> the backend to find the right application.
>
> For our case, this whole API is unimplementable. We would basically use:
so the restful spec allows a sort order, a set of fields to filter by,
pagination etc for each of the url endpoints. if your service chooses not to
support those than that is fine, but we need to allow some containers to
support sorting or paginating of activities and what not. its just the most
general interface i suppose. does that sound ok?
>
>
> public ResponseItem<RestfulCollection<T>> getItems(Set<String> fields,
> UserId userId,
> GroupId groupId,
> SortOrder sort,
> SortDirection direction, FilterType filter,
> int first, int max, SecurityToken token);
>
> And our implementation has a way of doing
>
> validate(userId, token); (Similar to getIds from PeopleService)
> String appId = someTransform(token);
>
> With "someTransform" either being a callback to our backend to get the
> information (bad, because roundtrippy) or better, we hand out all the
> needed stuff (fields, sort, direction, filter, first, max) and the
> token to the backend and it knows how to deal with this by looking
> into the token.
>
> BTW: When did groupId appear? Did I miss something? :-)
groupId comes from the rest urls as well - cause they all look like
/<type>/<userId>/<groupId>/...
like /people/john.doe/@friends or /people/john.doe/@self
so @friends or @self indicate the group. the restful spec also allows
arbitrary groups (as opposed to the special tokens)
>
> Ciao
> Henning
>
> --
> Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
> Open Source Consulting, Development, Design | Velocity - Turbine guy
>
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
> Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
>
> "Professor Peach in the library with the lead piping!" -- Donna
>
Re: The perfect social service interfaces
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Cassie <do...@apache.org> writes:
> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
> GroupId groupId, String appId, Set<String> fields, SortOrder sort,
> SortDirection direction, FilterType filter,
> int first, int max, SecurityToken token);
Why is "appid" needed? And especially, why is it in the method signature?
Some background: We are using a shindig install, where the secure
token is completely opaque and all information inside the token is
never visible to the java side. App id is a part of this
information. So we hand the token to our "backend", which also created
the token in the first place and knows how to decode it and rely on
the backend to find the right application.
For our case, this whole API is unimplementable. We would basically use:
public ResponseItem<RestfulCollection<T>> getItems(Set<String> fields,
UserId userId,
GroupId groupId,
SortOrder sort,
SortDirection direction, FilterType filter,
int first, int max, SecurityToken token);
And our implementation has a way of doing
validate(userId, token); (Similar to getIds from PeopleService)
String appId = someTransform(token);
With "someTransform" either being a callback to our backend to get the
information (bad, because roundtrippy) or better, we hand out all the
needed stuff (fields, sort, direction, filter, first, max) and the
token to the backend and it knows how to deal with this by looking
into the token.
BTW: When did groupId appear? Did I miss something? :-)
Ciao
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen
"Professor Peach in the library with the lead piping!" -- Donna
Re: The perfect social service interfaces
Posted by Chris Chabot <ch...@xs4all.nl>.
nope haven't taken the time to implement that yet, first priority is
to get it 100% with the javascript, then the rest once that's buttoned
down :)
putting transformation outside of the service would mean we save the
shindig users a lot of headaches implementing this.. sounds like the
right call to make
ps, wasn't my fav part of the spec either, hope there was a good
reason for it :)
-- Chris
On Jun 19, 2008, at 1:14 AM, Cassie wrote:
> Yuck, indexBy seems sorta gross. Does the php support this already?
> Perhaps we can push this transform outside of the service into some
> helper
> logic..
>
> On Wed, Jun 18, 2008 at 4:08 PM, Chris Chabot <ch...@xs4all.nl>
> wrote:
>
>> (not a response to the actual proposal, more of a general thing):
>>
>> Remember that the RESTful spec also mentioned having an indexBy,
>> so that
>> should be added (in whichever interface definition). An indexBy
>> should have
>> the following result (cut&paste from spec doc):
>>
>> {
>> "entry" :
>> [
>> { "id" : "example.org:34KJDCSKJN2HHF0DW20394", "pokes" : 3,
>> "last_poke" : "2008-02-13T18:30:02Z" },
>> { "id" : "example.org:58UIDCSIOP233FDKK3HD44", "pokes" : 2,
>> "last_poke" : "2007-12-16T18:30:02Z" }
>> ]
>> }
>>
>> application/json representation (with indexBy=id):
>>
>> {
>> "entry" : {
>> "example.org:34KJDCSKJN2HHF0DW20394" : {"pokes" : 3, "last_poke" :
>> "2008-02-13T18:30:02Z" },
>> "example.org:58UIDCSIOP233FDKK3HD44" : {"pokes" : 2, "last_poke" :
>> "2007-12-16T18:30:02Z" }
>>
>> }
>> }
>>
>> On Jun 19, 2008, at 12:57 AM, Cassie wrote:
>>
>> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
>>> GroupId groupId, String appId, Set<String> fields, SortOrder
>>> sort,
>>> SortDirection direction, FilterType filter,
>>> int first, int max, SecurityToken token);
>>>
>>
>>
Re: The perfect social service interfaces
Posted by Cassie <do...@apache.org>.
Yuck, indexBy seems sorta gross. Does the php support this already?
Perhaps we can push this transform outside of the service into some helper
logic..
On Wed, Jun 18, 2008 at 4:08 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> (not a response to the actual proposal, more of a general thing):
>
> Remember that the RESTful spec also mentioned having an indexBy, so that
> should be added (in whichever interface definition). An indexBy should have
> the following result (cut&paste from spec doc):
>
> {
> "entry" :
> [
> { "id" : "example.org:34KJDCSKJN2HHF0DW20394", "pokes" : 3,
> "last_poke" : "2008-02-13T18:30:02Z" },
> { "id" : "example.org:58UIDCSIOP233FDKK3HD44", "pokes" : 2,
> "last_poke" : "2007-12-16T18:30:02Z" }
> ]
> }
>
> application/json representation (with indexBy=id):
>
> {
> "entry" : {
> "example.org:34KJDCSKJN2HHF0DW20394" : {"pokes" : 3, "last_poke" :
> "2008-02-13T18:30:02Z" },
> "example.org:58UIDCSIOP233FDKK3HD44" : {"pokes" : 2, "last_poke" :
> "2007-12-16T18:30:02Z" }
>
> }
> }
>
> On Jun 19, 2008, at 12:57 AM, Cassie wrote:
>
> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
>> GroupId groupId, String appId, Set<String> fields, SortOrder sort,
>> SortDirection direction, FilterType filter,
>> int first, int max, SecurityToken token);
>>
>
>
Re: The perfect social service interfaces
Posted by Chris Chabot <ch...@xs4all.nl>.
(not a response to the actual proposal, more of a general thing):
Remember that the RESTful spec also mentioned having an indexBy, so
that should be added (in whichever interface definition). An indexBy
should have the following result (cut&paste from spec doc):
{
"entry" :
[
{ "id" : "example.org:34KJDCSKJN2HHF0DW20394", "pokes" : 3,
"last_poke" : "2008-02-13T18:30:02Z" },
{ "id" : "example.org:58UIDCSIOP233FDKK3HD44", "pokes" : 2,
"last_poke" : "2007-12-16T18:30:02Z" }
]
}
application/json representation (with indexBy=id):
{
"entry" : {
"example.org:34KJDCSKJN2HHF0DW20394" : {"pokes" : 3,
"last_poke" : "2008-02-13T18:30:02Z" },
"example.org:58UIDCSIOP233FDKK3HD44" : {"pokes" : 2,
"last_poke" : "2007-12-16T18:30:02Z" }
}
}
On Jun 19, 2008, at 12:57 AM, Cassie wrote:
> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
> GroupId groupId, String appId, Set<String> fields, SortOrder
> sort,
> SortDirection direction, FilterType filter,
> int first, int max, SecurityToken token);
Re: The perfect social service interfaces
Posted by "Jun Yang (杨骏)" <jy...@google.com>.
On Wed, Jun 18, 2008 at 4:05 PM, Kevin Brown <et...@google.com> wrote:
> On Wed, Jun 18, 2008 at 3:57 PM, Cassie <do...@apache.org> wrote:
>
> > Now Data doesn't -quite- fit with this model because it doesn't return a
> > List<T> it should return a Map<String, T> but yeah.. we can special case
> > that somehow for now or eventually be more standard and get rid of it. We
> > could also compose userId, groupId and appId into an object to remove
> some
> > of this overly large param list clutter or something...
>
>
> The last item makes me think that this is too generic-oriented. Why not
> just
> have separate interfaces for the different data types? Will you ever really
> be able to have generic consumers of the interfaces, or will they have to
> always know what the underlying objects are anyway? If there is a simple
> way
> to map request types -> interfaces, then the generics approach probably
> works, but otherwise it seems like you could avoid these issues entirely by
> just having distinct interfaces for each type of data.
>
"T" can be "T implements X", where X can be something generic like Entity or
other such things. The existing items do seem to share at least some
properties such as id and lastUpdated, etc. Then the handler code can be
super simple and generic.
"social service" makes me laugh.
>
:)
Jun
Re: The perfect social service interfaces
Posted by Cassie <do...@apache.org>.
Yeah.. you are probably right.. I just got really tired of adding String
appId to all of the services and making sure they all matched up. I suppose
its for the best though.
Thanks.
- Cassie
On Wed, Jun 18, 2008 at 4:05 PM, Kevin Brown <et...@google.com> wrote:
> On Wed, Jun 18, 2008 at 3:57 PM, Cassie <do...@apache.org> wrote:
>
> > Hey guys -
> >
> > So I was just starting to add a messaging service to the java code and I
> > saw
> > that the new java service interfaces still need a lot of cleanup. I also
> > noticed how similar they were to one another because of how structured
> the
> > rest calls have been making everything. So... I started thinking about a
> > generics based interface that could work for all of the different types
> of
> > objects we currently have and could hopefully extend to photos, movies,
> > etc.
> >
> >
> > Anybody want to give me some quick feedback on a simple service like
> this:
> >
> > // T is the type of model object that this service deals with. (I know,
> > crappy name, feel free to suggest a better one)
> > // T = Activity, Person, Message or Map<String, String> (ie Data)
> >
> > public interface ItemService<T> {
> >
> > public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
> > GroupId groupId, String appId, Set<String> fields, SortOrder sort,
> > SortDirection direction, FilterType filter,
> > int first, int max, SecurityToken token);
> >
> > public ResponseItem<T> getItem(UserId userId, GroupId groupId, String
> > appId,
> > Set<String> fields, String itemId, SecurityToken token);
> >
> > public ResponseItem<T> deleteItem(UserId userId, GroupId groupId, String
> > appId,
> > String itemId, SecurityToken token);
> >
> > public ResponseItem createItem(UserId personId, GroupId groupId, String
> > appId,
> > Set<String> fields, T item, SecurityToken token);
> >
> > // None of the services have this right now... but it maps to "put" in
> > rest. Will we ever actually use this call?
> > public ResponseItem updateItem(UserId personId, GroupId groupId, String
> > appId,
> > Set<String> fields, T item, SecurityToken token);
> >
> > }
> >
> > Now Data doesn't -quite- fit with this model because it doesn't return a
> > List<T> it should return a Map<String, T> but yeah.. we can special case
> > that somehow for now or eventually be more standard and get rid of it. We
> > could also compose userId, groupId and appId into an object to remove
> some
> > of this overly large param list clutter or something...
>
>
> The last item makes me think that this is too generic-oriented. Why not
> just
> have separate interfaces for the different data types? Will you ever really
> be able to have generic consumers of the interfaces, or will they have to
> always know what the underlying objects are anyway? If there is a simple
> way
> to map request types -> interfaces, then the generics approach probably
> works, but otherwise it seems like you could avoid these issues entirely by
> just having distinct interfaces for each type of data.
>
> "social service" makes me laugh.
>
>
> >
> >
> >
> > Alright, so, "horrible idea I've lost my mind" or "so, so idea I don't
> > think
> > it'll work long term" or "sure, go and refactor it".
> > Thanks.
> >
> > - Cassie
> >
>
Re: The perfect social service interfaces
Posted by Kevin Brown <et...@google.com>.
On Wed, Jun 18, 2008 at 3:57 PM, Cassie <do...@apache.org> wrote:
> Hey guys -
>
> So I was just starting to add a messaging service to the java code and I
> saw
> that the new java service interfaces still need a lot of cleanup. I also
> noticed how similar they were to one another because of how structured the
> rest calls have been making everything. So... I started thinking about a
> generics based interface that could work for all of the different types of
> objects we currently have and could hopefully extend to photos, movies,
> etc.
>
>
> Anybody want to give me some quick feedback on a simple service like this:
>
> // T is the type of model object that this service deals with. (I know,
> crappy name, feel free to suggest a better one)
> // T = Activity, Person, Message or Map<String, String> (ie Data)
>
> public interface ItemService<T> {
>
> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
> GroupId groupId, String appId, Set<String> fields, SortOrder sort,
> SortDirection direction, FilterType filter,
> int first, int max, SecurityToken token);
>
> public ResponseItem<T> getItem(UserId userId, GroupId groupId, String
> appId,
> Set<String> fields, String itemId, SecurityToken token);
>
> public ResponseItem<T> deleteItem(UserId userId, GroupId groupId, String
> appId,
> String itemId, SecurityToken token);
>
> public ResponseItem createItem(UserId personId, GroupId groupId, String
> appId,
> Set<String> fields, T item, SecurityToken token);
>
> // None of the services have this right now... but it maps to "put" in
> rest. Will we ever actually use this call?
> public ResponseItem updateItem(UserId personId, GroupId groupId, String
> appId,
> Set<String> fields, T item, SecurityToken token);
>
> }
>
> Now Data doesn't -quite- fit with this model because it doesn't return a
> List<T> it should return a Map<String, T> but yeah.. we can special case
> that somehow for now or eventually be more standard and get rid of it. We
> could also compose userId, groupId and appId into an object to remove some
> of this overly large param list clutter or something...
The last item makes me think that this is too generic-oriented. Why not just
have separate interfaces for the different data types? Will you ever really
be able to have generic consumers of the interfaces, or will they have to
always know what the underlying objects are anyway? If there is a simple way
to map request types -> interfaces, then the generics approach probably
works, but otherwise it seems like you could avoid these issues entirely by
just having distinct interfaces for each type of data.
"social service" makes me laugh.
>
>
>
> Alright, so, "horrible idea I've lost my mind" or "so, so idea I don't
> think
> it'll work long term" or "sure, go and refactor it".
> Thanks.
>
> - Cassie
>
Re: The perfect social service interfaces
Posted by "Jun Yang (杨骏)" <jy...@google.com>.
I think this interface looks great! In fact, I was going to suggest just
that. This give more structure and consistency to all APIs. Can't wait to
see it.
Jun
On Wed, Jun 18, 2008 at 3:57 PM, Cassie <do...@apache.org> wrote:
> Hey guys -
>
> So I was just starting to add a messaging service to the java code and I
> saw
> that the new java service interfaces still need a lot of cleanup. I also
> noticed how similar they were to one another because of how structured the
> rest calls have been making everything. So... I started thinking about a
> generics based interface that could work for all of the different types of
> objects we currently have and could hopefully extend to photos, movies,
> etc.
>
>
> Anybody want to give me some quick feedback on a simple service like this:
>
> // T is the type of model object that this service deals with. (I know,
> crappy name, feel free to suggest a better one)
> // T = Activity, Person, Message or Map<String, String> (ie Data)
>
> public interface ItemService<T> {
>
> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
> GroupId groupId, String appId, Set<String> fields, SortOrder sort,
> SortDirection direction, FilterType filter,
> int first, int max, SecurityToken token);
>
> public ResponseItem<T> getItem(UserId userId, GroupId groupId, String
> appId,
> Set<String> fields, String itemId, SecurityToken token);
>
> public ResponseItem<T> deleteItem(UserId userId, GroupId groupId, String
> appId,
> String itemId, SecurityToken token);
>
> public ResponseItem createItem(UserId personId, GroupId groupId, String
> appId,
> Set<String> fields, T item, SecurityToken token);
>
> // None of the services have this right now... but it maps to "put" in
> rest. Will we ever actually use this call?
> public ResponseItem updateItem(UserId personId, GroupId groupId, String
> appId,
> Set<String> fields, T item, SecurityToken token);
>
> }
>
> Now Data doesn't -quite- fit with this model because it doesn't return a
> List<T> it should return a Map<String, T> but yeah.. we can special case
> that somehow for now or eventually be more standard and get rid of it. We
> could also compose userId, groupId and appId into an object to remove some
> of this overly large param list clutter or something...
>
>
> Alright, so, "horrible idea I've lost my mind" or "so, so idea I don't
> think
> it'll work long term" or "sure, go and refactor it".
> Thanks.
>
> - Cassie
>