Rucheng Zhang Homework

.gitignore

@@ -0,0 +1,2 @@
+.idea
+target

.mvn/wrapper/maven-wrapper.properties

@@ -0,0 +1,18 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   https://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+distributionUrl=https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.8.7/apache-maven-3.8.7-bin.zip
+wrapperUrl=https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1.jar

HELP.md

@@ -0,0 +1,30 @@
+# Getting Started
+
+### User guide
+
+#### how to start the db?
+`cd docker &&`
+`docker-compose -f mysql.yml up`
+
+### USER AUTH
+
+the sequence of the user operation should be like
+
+register -> query -> update -> delete
+
+mapping to the API in our design should be:
+
+register:  /user/add
+query: /user/get   or /user/get/name
+update: /user/update
+delete: /user/delete
+
+for all the APIs above, except for the register API without auth, the rest all have the auth verification
+which means, only after login, the user can only operate with his/her own account
+
+## TODO
+we will use more advanced auto method in the future like JWT token based SSO.
+
+the followers impl will do in the future too.
+
+

README.md

@@ -4,18 +4,18 @@ Make sure you read the whole document carefully and follow the guidelines in it.
 
 ## Context
 
-Build a RESTful API that can `get/create/update/delete` user data from a persistence database
+Build a RESTful API that can `get/create/update/delete` userDo data from a persistence database
 
 ### User Model
 
 ```
 {
-  "id": "xxx",                  // user ID 
-  "name": "test",               // user name
+  "id": "xxx",                  // userDo ID 
+  "name": "test",               // userDo name
   "dob": "",                    // date of birth
-  "address": "",                // user address
-  "description": "",            // user description
-  "createdAt": ""               // user created date
+  "address": "",                // userDo address
+  "description": "",            // userDo description
+  "createdAt": ""               // userDo created date
 }
 ```
 
@@ -44,11 +44,11 @@ Build a RESTful API that can `get/create/update/delete` user data from a persist
 
 *These are used for some further challenges. You can safely skip them if you are not asked to do any, but feel free to try out.*
 
-- Provide a complete user auth (authentication/authorization/etc.) strategy, such as OAuth. This should provide a way to allow end users to securely login, autenticate requests and only access their own information.
+- Provide a complete userDo auth (authentication/authorization/etc.) strategy, such as OAuth. This should provide a way to allow end userDos to securely login, autenticate requests and only access their own information.
 - Provide a complete logging (when/how/etc.) strategy.
-- Imagine we have a new requirement right now that the user instances need to link to each other, i.e., a list of "followers/following" or "friends". Can you find out how you would design the model structure and what API you would build for querying or modifying it?
-- Related to the requirement above, suppose the address of user now includes a geographic coordinate(i.e., latitude and longitude), can you build an API that,
-  - given a user name
+- Imagine we have a new requirement right now that the userDo instances need to link to each other, i.e., a list of "followers/following" or "friends". Can you find out how you would design the model structure and what API you would build for querying or modifying it?
+- Related to the requirement above, suppose the address of userDo now includes a geographic coordinate(i.e., latitude and longitude), can you build an API that,
+  - given a userDo name
   - return the nearby friends