Skip to content

Commit e2cdce6

Browse files
arhimedearhimede
authored
Merge pull request #12 from dotkernel/arhimede
added flow pages
2 parents 5bdaee3 + bcccdd8 commit e2cdce6

File tree

8 files changed

+95
-0
lines changed

8 files changed

+95
-0
lines changed

‎docs/book/v4/core-features/content-negotiation.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
# Content Negotiation
2+
3+
**Content Negotiation** is performed by an application in order to :
4+
5+
- To match the requested representation as specified by the client via the Accept header with a representation the
6+
application can deliver.
7+
- To determine the `Content-Type` of incoming data and deserialize it so the application can utilize it.
8+
9+
Essentially, content negotiation is the *client* telling the server what it is sending and what it wants in return, and
10+
the server determining if it can do what the client requests.
11+

‎docs/book/v4/core-features/content-validation.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
# Basic Content Validation
2+
3+
https://github.com/dotkernel/api/pull/261/files

‎docs/book/v4/flow/default-library-flow.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# Default Library Flow
2+
3+
## The graph below demonstrates a default flow between DotKernel's libraries.
4+
5+
![Dotkernel API Default Library Flow!](https://docs.dotkernel.org/img/api/dotkernel-library-flow.png)

‎docs/book/v4/flow/library-flow-for-email.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# Library Flow for Email
2+
3+
## The graph below demonstrates the simplified flow between DotKernel's libraries for sending an email.
4+
5+
![Dotkernel API Default Library Flow!](https://docs.dotkernel.org/img/api/dotkernel-library-flow-email.png)

‎docs/book/v4/flow/middleware-flow.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# Middleware flow
2+
3+
## The graph below demonstrates a default flow between DotKernel's middlewares.
4+
5+
![Dotkernel API Middleware Flow!](https://docs.dotkernel.org/img/api/dotkernel-middleware-flow.png)

‎docs/book/v4/transition-from-api-tools/discovery-phase.md

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
# Discovery phase for a current system built using API Tools [WIP]
2+
3+
In order to transition a system built using api-tools to Dotkernel API , we need to analyze the core components
4+
of it.
5+
6+
## Database
7+
8+
- there is a database in the current API ?
9+
- which is the connection to database
10+
- which library is used for database interaction ( laminas-db, doctrine 2, eloquent, or else )
11+
12+
### Note
13+
14+
> Dotkernel API is tested only with MariaDB version 10.6 and 10.11 LTS
15+
16+
## Authentication and Authorization
17+
18+
- how authentication is done ? (basic, digest, oauth2, etc.)
19+
- how authorization is done ? (acl, rbac)
20+
21+
## Modules
22+
23+
- analyze configuration files of the modules (what needs to be configured in order to use a module)
24+
- analyze routes (which are the routes, protection rules, which one need auth, etc.)
25+
- analyze response format (content negotiation and validation, which ones are json, hal, views, etc.)
26+
- analyze input field validations
27+
28+
## Custom functionalities
29+
30+
Analyze the custom code (code that cannot be generated through Admin UI and require manual implementation)
31+
32+
For instance:
33+
34+
- caching
35+
- events
36+
- services
37+
- extra installed packages and libraries
38+
- jobs and queues
39+
- third-parties
40+
- tests

‎docs/book/v4/transition-from-api-tools/transition-approach.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
# Transition approach [WIP]
2+
3+
Dotkernel API is not a one-to-one replacement of api-tools ( former Apigility), but is only a potential solution to migrate to.
4+
5+
Functionalities, components and architecture are different.
6+
7+
See the [Comparison between Dotkernel APi and api-tools](https://docs.dotkernel.org/api-documentation/v4/transition-from-api-tools/api-tools-vs-dotkernel-api/)
8+
9+
## Business cases
10+
11+
There are at least 2 approaches for this transition:
12+
13+
### Clone 1:1
14+
and recreate all endpoints and entities
15+
16+
### Build a new version of the current API using Dotkernel API
17+
and keep it running as separate platforms until the sunset of the current version of api-tools

‎mkdocs.yml

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,10 +20,19 @@ nav:
2020
- "Doctrine ORM": v4/installation/doctrine-orm.md
2121
- "Test the Installation": v4/installation/test-the-installation.md
2222
- "FAQ": v4/installation/faq.md
23+
- Flow:
24+
- "Middleware Flow": v4/flow/middleware-flow.md
25+
- "Default Library Flow": v4/flow/default-library-flow.md
26+
- "Library Flow for Email": v4/flow/library-flow-for-email.md
27+
- Core Features:
28+
- "Content Negotiation": v4/core-features/content-negotiation.md
29+
- "Content Validation": v4/core-features/content-validation.md
2330
- Tutorials:
2431
- "Creating a book module": v4/tutorials/create-book-module.md
2532
- Transition from API Tools:
2633
- "API Tools vs DotKernel API": v4/transition-from-api-tools/api-tools-vs-dotkernel-api.md
34+
- "Transition Approach": v4/transition-from-api-tools/transition-approach.md
35+
- "Discovery Phase": v4/transition-from-api-tools/discovery-phase.md
2736
site_name: api
2837
site_description: "DotKernel API"
2938
repo_url: "https://github.com/dotkernel/api"

0 commit comments

Comments
 (0)