API requires more than 1 member to be added when creating new rooms

[propertunist]

this is how the code is configured presently, but how is that of benefit? if i am a site admin i might want to create rooms for others to come and join when i don't have any members (except maybe for me) to put in them.
i vote that this function be changed to place no limit on the numbers of members required to create a new room (or at least reduce it to 1).

[Deepakkothandan]

@propertunist can you please provide the name of the api method, that you are using ?? and also the rocketchat version.

[propertunist]

@Deepakkothandan - sure, it was:

api/bulk/createRoom

i have version 0.34.0 running here

[Deepakkothandan]

@propertunist please use the new api method rocketchat.domain.tld/api/v1/channel.addall to create a channel and rocketchat.domain.tld/api/v1/groups.create to create a private group. If I am not wrong the above api which you are using would be deprecated. #3541

[propertunist]

@Deepakkothandan i searched the rocket.chat sourcecode i am running here for any of the keywords you mentioned here, such as 'addall' and 'api/v1', but i found nothing of relevance. are you sure that the api upgrade is present in the version of rocket.chat i am using?

[Deepakkothandan]

@propertunist sorry I missed that, it was added in version 0.35.0.

[propertunist]

i see, ok. i notice that it was you that put the changes into 0.35.0. - are you open to adding further API calls too? i am currently figuring out how to connect rocket.chat to my own PHP based social network and am finding the process of doing so to be overly complicated. i started out attempting to sync them using rocketchat's API, but it is missing many of the functions i need. now i am battling to get a custom build of PHP7 working so that i can use pthreads, so that i can use DDP, so that i can communicate with rocket.chat from within PHP! it would be much easier if the API just had the needed functions in it.
e.g. a function to pass a url to rocket.chat to use for a user's avatar (without needing to login as that user)... and extensions to the createUser function to allow metadata to be added beyond just the basic login details.
any thoughts on that? thanks

[Deepakkothandan]

@propertunist Sure, I could help you with that. Please specify the functionalities that you would require and I believe Rocketchat core members, need to review and decide on which functionalities could be implmented

[propertunist]

@Deepakkothandan that would be really helpful, thanks :)

Functional specification: API extension for rocket.chat to facilitate syncing with external system

requirements:

allow a database driven software system to communicate with rocket.chat via rocket.chat's API and to fully synchronise data from the system with rocket.chat's database. The main types of data to be synchronised are:

• users and user metadata (including avatars).
• groups from a social network (which will be converted into channels with approriate metadata in rocket.chat).
• user authentication (ensuring that users are authenticated into rocket.chat only by use of the login details that are stored in the external system).

API functions needed:

users and user metadata (including avatars).

1. Create bulk users / create single user

Authorisation: called by administrator with appropriate role assigned

this could also act as an 'edit user' function by overwriting existing user data if it exists. otherwise a seperate API function for editing users would be necessary.

inputs:
name
username
email
password ?
url for avatar
access token for authentication ?

output:
success / error code

2. delete user

Authorisation: called by administrator with appropriate role assigned

inputs:
username

output:
success / error code

3. list users

Authorisation: called by administrator with appropriate role assigned

output:
object/array of users, each including user's – name, username, email and avatar url

channel and channel metadata

4. Create bulk channels(rooms) / create single channel(room)

this could also act as an 'edit user' function by overwriting existing user data if it exists. otherwise a seperate API function for editing users would be necessary.

Authorisation: called by administrator with appropriate role assigned

inputs:
channel name
privacy level (public/private)
channel description
members (array) – no minimum number of members if possible.

output:
success / error code

5. delete channel

Authorisation: called by administrator with appropriate role assigned

inputs:
channel name

output:
success / error code

6. list channels

Authorisation: called by administrator with appropriate role assigned

output:
object/array of channels, each including channel's – name, privacy level and number of members

user authentication

it may be sufficient to use the 'iframe method' that is briefly outlined here: #2767

I have been led to think that no new API functions are necessary to complete the sync between rocket.chat and an external system – however, any new API functions that might make the authentication process simpler are welcome.

[Sing-Li]

@propertunist Thank you for the excellent analysis. I should add that these methods will also be incredibly valuable for many bot and hubot implementers (a very fast growing segment of Rocket.Chat users/developers).

@Deepakkothandan It might be an opportune time also to rethink the architecture of how we are handling REST APIs in general. The Meteor coupling is really, in many ways, restrictive for very little return - when it comes to REST APIs. It would be ideal if it is possible to start one or more "REST API ONLY server instances" independent of their associated Rocket.Chat server instances - (perhaps a Meteor-free Express stacks) - and allow each of these instances to "saturate a core"; pushing the concurrency/lock handling bottleneck down towards the database. This will decouple the scaling of REST-API handling from Rocket.Chat server scaling in the longer term.

Thoughts / comments welcomed.

[propertunist]

@Sing-Li you are welcome. i think the idea of decoupling API processing from non API processes via allowing multiple servers to function in a child/parent relationship is a good one - however, from my perspective, it would be ideal if that task could be separated from the task of extending the API.. only because i really need the API functions to be in place before i can fully use rocket.chat in a production situation.

[propertunist]

@Deepakkothandan do you have any timespace to look at the API extensions this week? i probably will do in a couple of days. thanks

[propertunist]

i have just upgraded my version of rocket chat here to 0.44 and made my first successful audio/video call using chromium - so i am motivated again to look at extending the API. any help anyone can offer is appreciated here.