After #1057 is merged then it possible for the server implementation to add custom return types which isn't necessarily Result<T, E> i.e, it could a type that just implements IntoResponse. While this is a nice improvement for the server, it doesn't work for the clients as the responses could fail a bunch of reasons such as I/O, decoding errors and similar hence there are two client traits that returns Result<T, Error>.

Thus, currently Result<T, E> only works when both the client and server attributes are enabled at an API.
For example the following won't compile:

#[derive(Serialize)]
struct Custom;

impl IntoResponse for Custom {
	type Output = Self;

	fn into_response(self) -> PartialResponse<Self::Output> {
		let error_object = jsonrpsee::types::ErrorObjectOwned::owned(0, "custom_error", None::<()>);
		PartialResponse::Error(error_object)
	}
}

#[rpc(server, client, namespace = "foo")]
pub trait Rpc {
	#[method(name = "method1")]
	async fn method1(&self) -> Custom;
}

For example we could try to parse the return type if it's not a result type and generate:

  async fn method1(&self) -> Result<Custom, Error>;

This leads to question whether grouping the server and client is such a good idea since there are basically to much magic happens in the proc macro.

Thus, it might be better split them up but I still very much like the idea that an API can be shared by a server/client to avoid duplicated all things.