HackSoftware/Django-Styleguide
1
1
Fork 0
mirror of https://github.com/HackSoftware/Django-Styleguide.git synced 2024-11-10 19:56:40 +03:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #135 from nicksonlangat/fix-for-a-typo

Browse Source 
added a small fix for a typo
This commit is contained in:
Radoslav Georgiev 2023-08-08 09:52:55 +03:00 committed by GitHub
commit a96c84e962
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -919,7 +919,7 @@ When using services & selectors, all of your APIs should look simple & identical
- **Don't do business logic in your API.** - **Don't do business logic in your API.**
- You can do **object fetching / data manipulation in your APIs** (potentially, you can extract that to somewhere else). - You can do **object fetching / data manipulation in your APIs** (potentially, you can extract that to somewhere else).
- If you are calling `some_service` in your API, you can extract object fetching / data manipulation to `some_service_parse`. - If you are calling `some_service` in your API, you can extract object fetching / data manipulation to `some_service_parse`.
- Basically, keep the APIs are simple as possible. They are an interface towards your core business logic. - Basically, keep the APIs as simple as possible. They are an interface towards your core business logic.
When we are talking about APIs, we need a way to deal with data serialization - both incoming & outgoing data. When we are talking about APIs, we need a way to deal with data serialization - both incoming & outgoing data.