"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
