我们可以通过一个实际的需求，再深入了解一下应用的客户端与服务端的具体的职责，以及它们是怎么通过应用接口交换数据完成要做的事情的。
比如应用需要支持用户的注册与登录，要满足这个需求需要在应用里实现一些对应的业务，这里说的“业务”指的就是我们的应用需要处理的各种事务。这些业务都有各自的流程与逻辑，我们暂时先不考虑具体的实现，只需要先把这个业务的流程与逻辑描述清楚就行了，就是确定一下实现这个业务都需要执行哪些可能的动作，流程是什么，执行了动作以后又会发生什么。如果我们能用人类的语言把一个业务的流程与逻辑描述清楚，就一定能够使用机器语言把它设计并且实现出来。
要实现用户注册这个业务，应用的客户端需要提供一个注册界面，用户可以通过这个界面，输入想要注册的名字与密码，确定以后服务端需要处理这个注册请求，把要注册的用户相关数据保存到数据仓库里。要实现用户登录这个业务，用户可以在客户端提供的登录界面，输入之前他成功注册的用户名与密码，确定以后服务端会检查用户提供的登录信息，如果没有问题就会签发一个令牌交给客户端，以后客户端需要请求服务端接口的时候，要在请求里带着用户的令牌，这样服务端就可以通过这个令牌确定当前用户的身份了。
上面我们简单介绍了一下完成用户注册与登录的流程，客户端要提供注册与登录的界面，用户通过这些界面输入必要的数据，确定以后，客户端要带着用户输入的数据请求服务端提供的用户注册与登录接口来处理用户的注册与登录。
下面我们再考虑一些细节，用户在注册的时候要提供用户名与密码，确定以后，服务端会检查要注册的用户名与密码，如果用户名之前已经被别人注册了，这时服务端可以做出一个异常响应，告诉客户端用户名被人注册了，客户端收到服务端的响应以后做出自己判断，可以根据响应里的状态码或者其它一些因素来判断如何处理收到的响应，比如收到用户名被人注册的异常响应，这时客户端可以在界面上显示一条提示，告诉用户没能注册成功的具体的原因。
用户登录的时候要通过客户端的登录界面提供用户的身份数据，比如他的用户名与密码，确定以后客户端要带着这些数据请求服务端提供的登录接口，服务端的登录接口收到请求，会检查请求里带的用户的身份数据，如果检查出问题，比如用户名不存在或者密码不对，这时服务端可以做出异常响应，客户端收到响应做出判断，如果有异常就可以在用户界面上显示提示，告诉用户没能成功登录的具体的原因。
在设计服务端的注册用户接口的时候，可以规定客户端必须提供 JSON 这种格式的数据，数据里面要包含用户名与密码属性，属性的名字可以是 username 还有 password。客户端的注册用户界面可以通过一些表单元素向用户收集用户名与密码，然后组织好一个 JSON 格式的数据，里面包含了用户输入的 username 与 password，用户确定以后客户端会请求注册用户接口，请求里就会带着这些数据，服务端的注册用户接口收到客户端的请求，会从请求里提取这些数据，一切正常就可以将这些数据交给数据仓库里存储起来，然后通知客户端成功注册了用户，如果有异常情况可以通知客户端具体是哪里出了问题。
用户登录接口跟注册接口差不多，也需要客户端提供 JSON 格式的数据，里面包含用户名与密码，用户在客户端的登录界面输入用户名与密码，确定以后客户端会带着用户输入的登录数据请求服务端提供的用户登录接口，接口收到请求会根据请求里的用户名，从应用的数据仓库那里找到之前存储的这个用户数据，然后对比用户提供的密码与应用之前存储的密码是否匹配，一切正常就可以给用户签发一个令牌并交给客户端，如果有异常情况可以做出异常响应，客户端收到响应可以做出自己的判断，再决定如何处理收到的响应。
客户端要在请求里提供哪些数据，数据的格式是什么样的，得到响应以后如何根据不同的情况做出不同的处理，服务端怎么处理客户端发过来的请求，在什么情况下做出什么样的响应，所有这些事情都需要我们开发者自己来决定。应用里的业务的流程主要是由服务端主导的，服务端设计好了应用接口，定了一套规矩或者叫业务的逻辑，客户端需要按照这套规矩去设计与实现业务需要的用户界面。
