Show Menu

C# API Tech Interview Cheat Sheet (DRAFT) by

API related tech info

This is a draft cheat sheet. It is a work in progress and is not finished yet.

API Best Practices

Use JSON for sending and receiving data
Use noun instead of verbs in endpoints. EX: https:­//m­ysi­te.c­om­/ge­tPosts should be https:­//m­ysi­te.c­om­/posts
Collec­tions should use plural nouns. EX: https:­//m­ysi­te.c­om­/po­st/123 should be https:­//m­ysi­te.c­om­/po­sts/123
Use status codes for error handling
Use nesting on endpoints to show relati­ons­hips. EX: https:­//m­ysi­te.c­om­/po­sts­/author
Use filtering, sorting, and pagination so retrieve data requested. EX: https:­//m­ysi­te.c­om­/po­sts­?ta­gs=­jav­ascript
Use SSL for Security. EX: https:­//m­ysi­te.c­om­/posts runs on SSL and http:/­/my­sit­e.c­om/­posts does not run on SSL
Be Clear with Versio­ning. Common versioning system in semantic versio­ning. EX: 1.2.3 where 1 is the major version, 2 is the minor version, and 3 is the patch version. https:­//m­ysi­te.c­om/v1/
Provide accurate API docume­nta­tion. EX: Swagger, Postman

HTTP Headers

HTTP headers let the client and the server pass additional inform­ation with an HTTP request or response.
Request headers contain more inform­ation about the resource to be fetched, or about the client requesting the resource.
Response headers hold additional inform­ation about the response, like its location or about the server providing it
Repres­ent­ation headers contain inform­ation about the body of the resource, like its MIME type, or encodi­ng/­com­pre­ssion applied.
Payload headers contain repres­ent­ati­on-­ind­epe­ndent inform­ation about payload data, including content length and the encoding used for transport.

Design Patterns - Basics

Types of Design Patterns
Creati­onal, Struct­ural, Behavioral
SOLID Principles
Single Respon­­si­b­ility Principle
A class changes for only one reason
Open/Closed Principle
A class should be open for extension, closed for editing
Liskov's Substi­­tution Principle
Derived types should cleanly and easily replace base types
Interface Segreg­­ation Principle
Favor multiple single­­-p­u­rpose interfaces over composite
Dependency Inversion Principle
Concrete classes depend on abstra­­ct­ions, not vice-versa
What are design patterns?
Design patterns are solutions to software design problems you find again and again in real-world applic­ation develo­pment. Patterns are about reusable designs and intera­ctions of objects.

Design Patterns - Singleton

Singleton is a creational design pattern, which ensures that only one object of its kind exists and provides a single point of access to it for any other code. Singleton has almost the same pros and cons a
Advant­ages: Singleton pattern can implement interf­aces. Can be lazy-l­oaded and has Static Initia­liz­ation. It helps to hide depend­encies. It provides a single point of access to a particular instance, so it is easy to maintain.
Disadv­ant­ages: Unit testing is a bit difficult as it introduces a global state into an applic­ation. Reduces the potential for parall­elism within a program by locking.

Design Patterns - Creational

Abstract Factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Separate the constr­uction of a complex object from its repres­ent­ation so that the same constr­uction processes can create different repres­ent­ations.
Factory Method
Define an interface for creating an object, but let the subclasses decide which class to instan­tiate. Factory Method lets a class defer instan­tiation to subcla­sses.
Specify the kinds of objects to create using a protot­ypical instance, and create new objects by copying this prototype.
Ensure a class only has one instance, and provide a global point of access to it.

Design Patterns - Structural

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incomp­ati­bility interf­aces.
Decouple an abstra­ction from its implem­ent­ation so that the two can vary indepe­nde­ntly.
Compose objects into tree structures to represent part-whole hierar­chies. Composite lets clients treat individual objects and compos­itions of objects uniformly.
Attach additional respon­sib­ilities to an object dynami­cally. Decorators provide a flexible altern­ative to subcla­ssing for extending functi­ona­lity.
Provide a unified interface to a set of interfaces in a system. Façade defines a higher­-level interface that makes the subsystem easier to use.
Use sharing to support large numbers of fine-g­rained objects effici­ently. A flyweight is a shared object that can be used in multiple contexts simult­ane­ously. The flyweight acts as an indepe­ndent object in each context; it’s indist­ing­uis­hable from an instance of the object that’s not shared.
Provide a surrogate or placeh­older for another object to control access to it.

Design Patterns - Factory Method

The Factory Method is one of the most known Design Patterns and often used when creating things with same behavior, but with different specif­ica­tions.
EX: Things with same behaviour, but different specif­ica­tions: Animal Factory, Logistics Factory (delivery method or transport vehicle)
Classes to be created cannot be determined in advance, therefore an abstract interface is provided which can be reached via a function
A class expects from its subclasses a specif­ication of the products to be created
Specia­liz­ation options for subcla­sses, as this pattern provides an extended version of the object compared to the direct creation of the object

Design Patterns - Behavioral

Chain of Resp.
Avoid coupling the sender of a request to its receiver by giving more then one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
Encaps­ulate a request as an object, thereby letting you parame­terize clients with different requests, queue or log requests, and support undoable operat­ions.
Given a language, define a repres­ent­ation for its grammar along with an interp­reter that uses the repres­ent­ation to interpret sentences in the language.
Provide a way to access the elements of an aggregate object sequen­tially without exposing its underlying repres­ent­ation.
Define an object that encaps­ulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explic­itly, and lets you vary their intera­ction indepe­nde­ntly.
Without violating encaps­ula­tion, capture and extern­alize an object’s internal state so that the object can be restored to this state later.
Define a one-to­-many dependency between objects so that when one object changes state, all its dependents are notified and updated automa­tic­ally.
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
Defines a family of algori­thms, encaps­ulates each one, and make them interc­han­geable. Strategy lets the algorithm vary indepe­ndently from clients who use it.
Template Method
Define a skeleton of an algorithm in an operation, deferring some steps to subcla­sses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithms structure.
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Dependency Injection Pattern

Dependency Injection (DI) is a design pattern used to implement IoC. It allows the creation of dependent objects outside of a class and provides those objects to a class through different ways. Using DI, we move the creation and binding of the dependent objects outside of the class that depends on them.
The Dependency Injection pattern involves 3 types of classes:
Client Class: The client class (dependent class) is a class which depends on the service class.
Service Class: The service class (depen­dency) is a class that provides service to the client class.
Injector Class: The injector class injects the service class object into the client class.

Repository Design Pattern

The Repository Design Pattern in C# Mediates between the domain and the data mapping layers using a collec­tio­n-like interface for accessing the domain objects. This isolates the data access code from the rest of the applic­ation.
Advant­ages: Changes can be done in one place. Testing the controller is easier as you don't have to test against the database.