DEV Community

Cover image for Consuming a Standard API: An MVC Real Estate Example
Jose Maria Iriarte
Jose Maria Iriarte

Posted on

Consuming a Standard API: An MVC Real Estate Example

In this article, we will survey the process of consuming a .NET API service using a real estate application as an example.

Throughout this guide, we will delve into the integration of a .NET MVC application with an existing API (a .NET API app which is included in the repository).

GitHub logo tigerbluejay / MVC-App-Consuming-BARE-API

.NET MVC App consuming the Buenos Aires Real Estate API. The application displays Apartment Complex and Apartment Unit information, allows for CRUD operations and implements .NET Identity for registration and login.

MVC App Consuming Buenos Aires Real Estate (BARE) API

An MVC application consuming the BARE API Service, able to perform CRUD operations on the data retrieved, and able to send data to the API.

The application works with the Buenos Aires Real Estate API, which is a a real state API service exposing Apartment Unit Rental Information in the City of Buenos Aires.

Disclaimer

Note: There is another repository containing the standalone implementation of the Buenos Aires Real Estate API. It can be found here. Note that the standalone implemnetation has some differences with the Buenos Aires Real Estate API that is part of this project. This is so, as changes were made during the development of the MVC App in the Buenos Aires Real Estate API (that is part of this Repo) to make the MVC Application compatible with that API.

Note however that the API in the…

The MVC application will facilitate actions such as reading, creating, updating, and deleting information via API service calls, all within a user-friendly UI.

Let's break down the components and steps involved in this integration.

Project Structure

The MVC API-Consuming Service Solution comprises three essential projects:

  • MVC Web Project: This houses the core functionality of the application.
  • Models Project: This project contains the models and DTOs (Data Transfer Objects) that mirror those of the API.
  • Utilities Project: This project provides auxiliary code to support object mapping functionalities (using the AutoMapper package).

Project Structure - Solution Explorer

Integration Overview

The MVC app communicates with the API endpoints to perform CRUD (Create, Read, Update, Delete) operations on information related to Apartment Complexes and Apartment Units. Notably, this information is not stored directly in the MVC app's database. Instead, it is available through the API endpoints of the API app, which does itself then communicate with its own database.

Landing Page

User Interface and Operations

Users access the application from the main menu on the home page. They can visualize information about Apartment Complexes and Apartment Units. Interaction with the API occurs through a set of services defined within the MVC app. Users can perform CRUD operations after registering and logging in.

Login

Manage Apartment Complexes

Update Apartment Complex

Authentication and Authorization

The MVC app incorporates an Authentication Service responsible for sending user credentials and login tokens to authenticate users for API consumption. Communication is managed through LoginRequestDTO and LoginResponseDTO. The implementation of sessions enables the MVC app to recognize and maintain user login status.

API endpoints are restricted to logged-in users with the "admin" role, which is the default role for all users. Similarly, certain pages within the MVC app for performing CRUD operations are restricted to "admin" role users.

MVC App Components

The MVC app consists of three main pillars:

  1. Authentication Functionality: Handles user registration and login.
  2. Apartment Complex Functionality: Manages CRUD operations for apartment complexes.
  3. Apartment Unit Functionality: Manages CRUD operations for apartment units.

Manage Apartment Units

Delete Apartment Unit

Each pillar (Auth, ApartmentComplex, ApartmentUnit) is supported by components:

  • Controllers: These direct traffic between views and services, invoked based on the requested URL. There's a controller for each pillar.
  • Views: User interfaces that display information and receive input. Views gather information, such as login credentials or data for updating/creating apartment complexes.
  • DTOs: These mirror the DTOs defined in the API project, facilitating seamless communication between views, controllers, and services.
  • Services: Each pillar has a dedicated service, and they inherit from a base service. Services configure requests, handle serialization/deserialization, and interact with API endpoints.

Relationship with the API Project

The API Project is integrated into the solution as four separate projects. A detailed discussion of the API Project can be found in its own repository's readme file (that is, there exists a near duplicate repository containing only API related code).

GitHub logo tigerbluejay / Buenos-Aires-Real-Estate-API

A real estate API service exposing apartment complex and apartment unit related (CRUD) endpoints. The service also integrates .NET identity for login, registration and authentication.

Buenos-Aires-Real-Estate-API

A real state API service exposing Apartment Unit Rental Information in the City of Buenos Aires.

Project Structure

The API Service Solution is comprised of four core projects: The API which houses core functionality, a Data Project which handles data access, a Models Project which contains the Models and DTOs for the Solution and a Utilities Project with ancilliary code to assist.

BuenosAiresRealEstate.API

Controllers

The API Project houses the two core sections of the Project. One is the Controllers, which are defined in different version folders. Version 2 of the ApartmentComplexController serves to show how you can work with in memory data. But the core controllers are the ApartmentComplexController and the ApartmentUnitController. Each apartment complex has units associated to it, and both can be retrieved (Get All and Get by Id), created, updated and deleted with the methods defined in these controllers. There is also a UsersController which implements…

Minor discrepancies exist between the standalone API Repository and the one integrated with the MVC App, primarily related to data types within DTOs and Models. Despite these differences, approximately 99% of the projects' code remains consistent, so reading the standalone API's documentation will be of great use in understanding the code in the MVC App.

The standalone GitHub repo's readme.md file offers a comprehensive treatment of the API Project. Feel free to explore this file, as well as the standalone project, to gain a deeper understanding of the API integration.

Also if you wish, you may check out my post dealing with this project: Navigating a Standard .NET API: A Real Estate Example

In Closing

By exploring the github repo linked at the beginning of the article (the MVC App and its corresponding API), you can gain insights into effectively consuming a .NET API service within a real-world context.

Top comments (1)

Collapse
 
leowhyx profile image
Leowhyx

Intresting post