It's theoretical question about class design (Objective-C, RestKit).
I started project few days ago, I wrote some tests and here is moment when I've got how response from server will looks. Application will be using RestKit. In the app one of classes will be e.g. ABCUser. Application should be able to register and login user to the serwer with credentials and server should return full ABCUser object. How it should be designed on client (iOS App) side?
Now I've got ABCUser class which has properties like username, password, email, and other stuff and there is category ABCUser+API which has got class methods uses to communicate with server (registerUser:withBlock:, loginUser:withBlock, logoutUser:withBlock:). When I want to register user by app I need to create ABCUser object only with credentials and I have to send it to the server, Then i receive full object from server. Is it good design?
Maybe I should use some Proxy object of ABCUser class to login? This class will have only credentials-like attributes. Is it good conception?
Maybe good solution is to create some service classes for register and logging user? Maybe ABCRegisterService and ABCLoginService?
Thank you in advance for your comments.
This is rather opinion based and depends on what you're used to and comfortable with. Your current solution is acceptable and minimalist. It's relatively clear what the category is for and should be maintainable in the future.
Your other suggestions add more classes for little perceived benefit. They will remove code that can be classed as inappropriate from the model but they also make the code base more verbose and harder to understand and maintain. Unless you have an overall service or proxy based approach this is unlikely to help.
The main things that could be lacking from your current solution is overall API structure and activity / connection management. By placing the API methods in a category on each model object it's harder to see the API shape and you add meaningless dependencies between the model objects as the API grows and allows more complex (useful) features. It's also harder to manage the number of concurrent connections. The appropriate solution to this could be a singleton data controller which provides a public interface of the API in terms of your model objects and contains (hides internally) all of the mapping information and interaction with the server.