API routes & functions considerations

[andreweinkoetz]

Please comment your required endpoints and their functionality below this issue.
I will split them into multiple issues once we gathered some endpoints.

Current top-level routes are:

• /auth (for user & authentication purposes)
• /ingredient (for all queries regarding ingredients)
• /recipe (for all queries regarding recipes)

From my point of view there would be one route i would like to add:

• /auth/changepw (to enable user to change his password)
• /recipe/ (POST) with recipe as json, to insert new recipe
• /recipe/:id (GET) to receive details of a specific standard recipe

For the user profile, we need following routes to post and delete:

• user/:id/goal
• user/:id/dislike
• user/:id/allergy
• user/:id/lifestyle
• user/:id/locale (to save 'en' or 'de' as users language preference)

aggregated in issue #5

To create and update a user recipe, we need:

• user/:id/recipe/ (for update)
• user/:id/recipe/ (for create)

aggregated in issue #7

Further improvement:

All userId related endpoints will be replaced.
Reason:
The user id is provided with after validating the access token. Selection via req.params is therefore not necessary and can be replaced:

• i.e. user/:id/allergy/ will be accessible on user/allergy

See #9 for this

[andrelandgraf]

For the user profile, we need following routes to post and delete:

• user/:id/goal/:id
• user/:id/dislike/:id
• user/:id/allergy/:id
• user/:id/lifestyle/:id
• user/:id/locale/:locale (to save 'en' or 'de' as users language preference)

To create and update an user recipe, we need:

• user/:id/recipe/:id (for update)
• user/:id/recipe/ (for create)

To get all those information, we already have the endpoint auth/me, to get the current user!

We also need an element endpoint for the different allergies (e.g. lactose, glucose)
/element(s)

And
/lifestyle(s)
/goal(s)

And last but not least, depending on the data schema, we will need an endpoint to rate substitute according to user feedback (e.g. I like the substitue, I do not like the substitute...)

[andreweinkoetz]

User endpoints added to checklist 👍

We also need an element endpoint for the different allergies (e.g. lactose, glucose)
/element(s)

And
/lifestyle(s)
/goal(s)

You mean the user-based allergies, lifestyle & goals right? (e.g. /user/:id/allergies)

And last but not least, depending on the data schema, we will need an endpoint to rate substitute according to user feedback (e.g. I like the substitue, I do not like the substitute...)

This is not part of the model yet. In my opinion this should be part of "UserRecipe"-model right?

[andrelandgraf]

This is not part of the model yet. In my opinion this should be part of "UserRecipe"-model right?

You are right, it should be!

You mean the user-based allergies, lifestyle & goals right? (e.g. /user/:id/allergies)

Exactly, a user needs to select a goal, lifestyle and allergies from a list of possible values. Those values, e.g. all goals, should be in the database and accessible like recipes or ingredients. :) So that, by calling /user/:id/goal/:id I can add the goal id from the goal endpoint to the user object.

[andreweinkoetz]

Exactly, a user needs to select a goal, lifestyle and allergies from a list of possible values. Those values, e.g. all goals, should be in the database and accessible like recipes or ingredients. :) So that, by calling /user/:id/goal/:id I can add the goal id from the goal endpoint to the user object.

Got this 👍 i will create a separate issue for the user-related endpoints.

Regarding UserRecipe - how about this model?

const UserRecipeSchema = new Schema( {
    user: {
        type: Schema.Types.ObjectId,
        ref: 'User',
    },
    recipe: {
        id: {
            type: Schema.Types.ObjectId,
            ref: 'Recipe',
        },
        substitutions: [ {
            orig: {
                type: Schema.Types.ObjectId,
                ref: 'Ingredient',
            },
            subs: [ {
                id: {
                    type: Schema.Types.ObjectId,
                    ref: 'Ingredient',
                },
                rating: {
                    type: Schema.Types.Boolean,
                    ref: 'Recipe',
                },
            } ],
        } ],

    },

}, { collection: 'userRecipe' } );

😃

[andreweinkoetz]

user/:id/goal/:id
user/:id/dislike/:id
user/:id/allergy/:id
user/:id/lifestyle/:id

If we'd model it this way, we would use the id ambiguously.
req.params.id would be one of userId or goalId (e.g.).

Suggestion:
user/:id/lifestyle/:lifeStyleId

or even easier (as you'll send me an object in the body of the request anyway):
user/:id/lifestyle/ with lifestyle as json in body

[andreweinkoetz]

user/:id/recipe/:id (for update)
user/:id/recipe/ (for create)

Implementation as:

user/recipe (PUT) for updating with personalized recipe as JSON in body
user/recipe (POST) for inserting with personalized recipe as JSON in body

We don't need to explicitly set :id for user in this route as the personalized recipe already includes the user's id.

[andreweinkoetz]

Further improvement:

All userId related endpoints will be replaced.
Reason:
The user id is provided with after validating the access token. Selection via req.params is therefore not necessary and can be replaced:

• i.e. user/:id/allergy/ will be accessible on user/allergy

Added description of this in original post. We need to keep in mind to remove all :id params in user-related routes.