Expand my Community achievements bar.

is there a call that will retturn accid

Avatar

Former Community Member
currently I am determining accid this way :



String acctid[] = contentPath.split("/");

account.setID(acctid[acctid.length-1]);



I dont want to parse roomInstance url becase what if there
are no rooms? will I still get roomInstance url?

(I guess I can delete my rooms and then test :))

also is there a chance that accountPath format to change in
the future?

from: "/accounts/bkf/account-id" to soomething with moer "/"
?

if so, maybe there is the way to just get accid ?

(some secret rest call?)

4 Replies

Avatar

Employee
If I may ask, why do you need the account id ?



The correct way is to use roomInstance in the AccountManager.

If you are working with an account URL the instance will be
something like <account-id>/#room# (if you are working with a
room URL it will be <account-id>/<room-id>)



And yes, there are good chances that the accountPath will
change in the future. The content repository we are using now may
not be the final one, and we are working on a way for developers to
supply their content repository. In any case we are planning to
mantain the high level API but the format of REST request/responses
may change so please don't rely on it.

Avatar

Former Community Member
the reason I need accid because contentPath and roomInstance
both share accid embebed in them,

since I am creating Account object, I want to just have accid
string in it

and use that to compose accountContentpath and roonInstance
Strings.

that also eliminates string splitting etc later on when only
accid is needed, for example call:



app/account?account=" + acctid

needs it. (to get accountInfo)





Avatar

Employee
the provided scripts already do "the right thing" so I am not
sure of why you are reimplementing it all, unless you are porting
it to a different language, in which case we would appreciate if
you would contribute it back.



Also, as I said, the implementation of some of the REST API
may change in the future (until I am happy with it and officially
document it :)

so you would be better off using the provided scripts, that
don't expose the implementation.



Avatar

Former Community Member
yes, definitely I will contribute full source once I am done,
(almost there ).

and I made it such a way that it counts for possible changes
in api.