ActivityStreams Service defects
mmarum-sugarcrm opened this issue · 6 comments
Original author: laurentw...@gmail.com (June 12, 2012 11:05:29)
Crossposting: http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/f70e462d81a99375/8f78bfe9028eaa2d
Hi all,
i have noticed various unclear definitions in the REST version of the
ActivityStreams service (in Social-API spec) for which i would like to
get clarifications:
- in section 2.3.1 (GET), the path requires the App-Id to be inserted
when requesting info about a specific (list of) activity. this seems
to be copied from the "old" activity service but i couldn't find other
methods (post, put,delete) on that service nor on any other service
(except appdata) that would make use of this app-id in the uri-
fragment. what is the concrete need for this and if so why is it only
used 1) when requesting information about a specific activity and not
for @ALL, @friends etc, and 2) when requesting activities and not
people, groups etc. could this be eventually removed? - in section 2.3.3 (PUT) the path does not include any reference to
the single activity-id, which presumably can be derived from the id of
the ActivityEntry JSON in the body. A better REST design for updating would expect a put on the resource itself, identified in the path through its id, so why this choice? it seems that shindig (php) already support the id-enhanced path. - in section 2.3.4 (DELETE) the same issue happens. in that case
though there is no body part so the server would have no indication of
which activity to delete. here again shindig supports the activityId
in the rest uri fragment to delete that specific activity so propbably
the spec would need to be aligned i guess. otherwise how would the
server expect the specific activity to be deleted? Note that the
example in 2.3.4.1 does not help neither as it seems a mix of rest/
rpc...
walter
Original issue: http://code.google.com/p/opensocial-resources/issues/detail?id=1320
From mgmarum@gmail.com on March 15, 2013 14:30:06
-
So the idea with App-Id is that you could have an activity stream per person per app. I think Jive might be using this convention, we should sync up with Mark W. about that.
-
As far as I'm concerned, this looks like an oversight. I would be fine with adding an optional Activity-Id to PUT.
-
Same.
From laurentw...@gmail.com on March 26, 2013 15:29:23
Attached is a patch that provides the following:
- adds an optional reference to Activity-Id in the REST-URI when updating an activity (2)
- adds a reference to Activity-Id in the REST-URI when deleting an activity (3)
(1) is not addressed/closed in this patch awaiting comments
From rbaxte...@gmail.com on March 27, 2013 21:27:42
Walter can you put draft tags around the changes?
From mgmarum@gmail.com on March 29, 2013 20:28:25
I can add draft tags while I apply patch. I usually go in and add discussion tags too, etc.
From mgmarum@gmail.com on March 29, 2013 21:25:39
Patch applied in r1712.
+1