Restaurant App API

A RESTful backend for a restaurant ordering system, built with ASP.NET Core 9 and Entity Framework Core. It powers the Restaurant App Flutter client — handling the menu, orders, JWT-based authentication and Stripe payments.

---

Overview

This project is the server side of a full-stack restaurant ordering app. The goal was to keep the API small but production-minded: a clean controller layer, async EF Core data access, token-based auth on top of ASP.NET Identity, and secrets kept out of source control.

Features

• Authentication & authorization — registration and login via ASP.NET Core Identity, stateless JWT Bearer tokens, role-based claims.
• Menu — food categories and foods, including a "most ordered" sorting endpoint per category.
• Orders — create orders and order items, fetch an order and its items by id.
• Payments — server-side Stripe PaymentIntent creation; the client never sees the secret key.
• Swagger / OpenAPI — interactive docs with a Bearer auth button for trying secured endpoints.

Tech Stack

Layer	Technology
Framework	ASP.NET Core 9 (Web API)
ORM	Entity Framework Core 9 (Code-First + Migrations)
Database	SQL Server
Identity	ASP.NET Core Identity (IdentityRole<int>, IdentityUser<int>)
Auth	JWT Bearer (Microsoft.AspNetCore.Authentication.JwtBearer)
Payments	Stripe.net
Docs	Swashbuckle (Swagger UI)

Project Structure

RestaurantAppAPI/
├── Controllers/        # API endpoints (Users, FoodCategories, Foods, Orders, OrderItems, Payment)
├── Models/             # EF Core entities + DbContext (RestaurantAppContext)
├── DTO/                # Request/response shapes (Login, Register, CreateOrder, ...)
├── Migrations/         # EF Core schema history
├── Program.cs          # Composition root: DI, auth, Identity, CORS, Swagger, role seeding
└── appsettings.json    # Configuration (no secrets committed)

Getting Started

Prerequisites

• .NET 9 SDK
• SQL Server (LocalDB, Express or full)
• EF Core tools: dotnet tool install --global dotnet-ef

1. Clone

git clone https://github.com/YusufUguz/RestaurantAppAPI.git
cd RestaurantAppAPI

2. Configure the database

appsettings.json ships with a local default:

"ConnectionStrings": {
  "ConnectionString": "Server=localhost;Database=restaurantapp;Trusted_Connection=True;TrustServerCertificate=True;"
}

Adjust Server= if your SQL Server uses a named instance.

3. Provide secrets (kept out of the repo)

Secrets are read from configuration but are not committed. Set them locally with user-secrets:

dotnet user-secrets init
dotnet user-secrets set "AppSettings:Secret"      "<a-long-random-string-for-jwt-signing>"
dotnet user-secrets set "Stripe:SecretKey"        "<your-stripe-secret-key>"
dotnet user-secrets set "Stripe:PublishableKey"   "<your-stripe-publishable-key>"

4. Create the schema and run

dotnet ef database update    # applies migrations, creates the database
dotnet run

The default "User" role is seeded automatically on startup, so registration works against a fresh database. Swagger UI is available at the root once the app is running (/swagger).

API Endpoints

Method	Route	Description
POST	/api/Users/register	Create an account
POST	/api/Users/login	Authenticate, returns a JWT
GET	/api/getallcategories	List food categories
GET	/api/getallfoods	List all foods
GET	/api/getfoodsbycategory?categoryID=	Foods in a category
GET	/api/getcommonorderedfoodsbycategory?categoryID=	Foods in a category, most ordered first
POST	/api/createorder	Create an order
GET	/api/getorderbyid?ID=	Get an order by id
POST	/api/createorderitem	Add an item to an order
GET	/api/getorderitemsbyorderid?OrderID=	Items of an order
POST	/api/create-payment-intent	Create a Stripe PaymentIntent

Security Notes

A few decisions worth calling out:

• No secrets in source control. JWT signing key and Stripe keys live in user-secrets / environment configuration; appsettings.json only holds placeholders.
• The Stripe secret key stays server-side. PaymentController creates the PaymentIntent and returns only the clientSecret to the app, so the secret key is never shipped to the client.
• Password & lockout policy is configured through Identity (minimum length, complexity, 5-attempt lockout).
• Stateless auth with signed JWTs validated on every request.
• HTTPS redirection is enabled outside of Development.

License

Released under the MIT License.