2 Replies Latest reply on Sep 22, 2013 3:43 PM by bandersen

    REST v3.x: Member service interpretation and invocation


      I have questions regarding the interpretation of the documentation associated with the REST v3.x member service's create member call.  My goal is to simply add an existing user to an existing group.


      The documentation for the create member call is as follows:


      POST /members/places/{placeID}


      I'm assuming (perhaps incorrectly) that the placeID placeholder is the id associated with the group to which I'm adding a user.  The documentation for placeID is somewhat misleading:


      placeID     ID of the social group member that will have the user as a new member


      Prior to invoking the call to add the user to a group, I call the place service, and use the values in the response to create a map associating numeric group ids with group names.  From this map (as well as checking the database), I know for certain that the group to which I want to add the user exists.  For the purpose of this question, assume that the group id is 1001.  It is also an open group, created by the Jive administrator, and visible to the user I want to add to the group.


      When invoking /members/places, I substitute the value 1001 for placeID, and pass to the call a request entity representing the string-ified JSON representation of the user's data, as specified in the documentation.


      What I receive in return is the following:


      POST request for "http://localhost:8080/api/core/v3/members/places/1001" resulted in 400 (Bad Request); invoking error handler


      suggesting that "An input field is missing or malformed".


      What's curious is that, stepping through the MemberService code, when createMember() attempts to validate the place (using the placeID value of 1001), the browseObjectCache CacheBean returns an EntityDescriptor whose objectType value is 2020 (representing a usercontainer object) and not something that identifies the place as a group (such as an EntityDescriptor with an objectType value of 700, identifying a social group).  In addition, the objectID of the returned EntityDescriptor is 3, not 1001, the value passed as placeID.


      Any thoughts on what I could be doing wrong, or how I am misinterpreting the REST API's documentation?  Thanks!

        • Re: REST v3.x: Member service interpretation and invocation

          The placeID is not the ID of the social group, it's the browseID.  These are unique across all places and content.  The reason you're getting back a different container than what you've passed in is because that's the container for browse ID 1001.


          To get the placeID you need to use a filter on the place api:


          1 person found this helpful
            • Re: REST v3.x: Member service interpretation and invocation

              Thanks, Steve -- This was helpful.


              The rub is that either 1) the placeID value isn't explicitly returned in the response from the call to the places service, or 2) I'm simply not seeing it.  However, neither of these matters, as the group's placeID value is surfaced among the place's resources.


              For example, among the returned place's resources is the self object, which includes among its members a URI capable of being used to retrieve metadata associated with itself:













              It's the "1008" on the end of the self object's ref URI that I'm interested in; the "1008" is the specified group's placeID value.  Retrieving this value is as simple as:

              1. Retrieving the value of the ref URI, then
              2. Using a regular expression to obtain the URI's trailing numeric value; e.g. ".+/(\\d+)$".