Updated account restrictions endpoints

[Vektrat]

@fboucquez @rg911

[dgarcia360]

I know that we are close to the deadline, but due to this change we might want to reconsider applying metadata's suggestions from @rg911 to achieve consistency between endpoints.

One of the reasons for not having separated metadata was due to the account restrictions endpoint structure:

Also, I don't see metadata as a single entity that works by its own. Taking into consideration similar features that depend on others (restrictions, multisig), we are creating endpoints under each main independent concept (e.g. /account/<:id>/restrictons, /account//multisig).

[Vektrat]

I know that we are close to the deadline, but due to this change we might want to reconsider applying metadata's suggestions from @rg911 to achieve consistency between endpoints.

One of the reasons for not having separated metadata was due to the account restrictions endpoint structure:

Also, I don't see metadata as a single entity that works by its own. Taking into consideration similar features that depend on others (restrictions, multisig), we are creating endpoints under each main independent concept (e.g. /account/<:id>/restrictons, /account//multisig).

i don't really understand the suggestend endpoints here, maybe a list of endpoints + example result would help

but those are my concerns from what i think i understand: i don't see the benefits of this, what does metadata have to do with mosaic restrictions?
also, returning all the metadata given an accountId seems to me like it would be fetching a lot of data from the database and most of it would probably be useless to the client (i think fetching metadata by resource makes more sense than by accountId)

the only thing that makes sense to me, organizationally, is to have the endpoints such as /metadata/{type}/{other_params_conditional_to_type}/, which does not really reduce the number of endpoints

[dgarcia360]

@Vektrat Sorry for not being too specific, you are right. I was referring only to this change:

the only thing that makes sense to me, organizationally, is to have the endpoints such as /metadata/{type}/{other_params_conditional_to_type}/, which does not really reduce the number of endpoints