Skip to Content
Last modified by Erik Bakker on 2024/09/03 08:20
From version 10.1
edited by Danniar Firdausy
on 2023/10/09 08:32
Change comment: There is no comment for this version
To version 4.1
edited by Erik Bakker
on 2022/06/13 10:07
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.dfirdausy
1 +XWiki.ebakker
Default language
... ... @@ -1,1 +1,0 @@
1 -en
Content
... ... @@ -3,6 +3,9 @@
3 3  
4 4  Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
6 +* Last update: December 2021
7 +* Required reading time: 10 minutes
8 +
6 6  == 1. Prerequisites ==
7 7  
8 8  * Advanced knowledge of the eMagiz platform
... ... @@ -13,8 +13,8 @@
13 13  
14 14  Please refer to the following Fundamentals to learn the key concepts of both patterns
15 15  
16 -* [[eMagiz API Gateway>>doc:Main.eMagiz Academy.Fundamentals.fundamental-api-gateway-introduction||target="blank"]]
17 -* [[eMagiz Messaging>>doc:Main.eMagiz Academy.Fundamentals.fundamental-messaging-introduction||target="blank"]]
19 +* [[eMagiz API Gateway>>doc:Main.eMagiz Academy.Fundamentals.fundamental-api-gateway-introduction.WebHome||target="blank"]]
20 +* [[eMagiz Messaging>>doc:Main.eMagiz Academy.Fundamentals.fundamental-messaging-introduction.WebHome||target="blank"]]
18 18  
19 19  == 3. Considerations for API Gateway or Messaging ==
20 20  
... ... @@ -34,19 +34,25 @@
34 34   ** Messaging required a fixed contract between the message definitions that are exchanged. A change of definition would result in validation issues and therefore more communication is required
35 35   ** For an API Gateway solution, the contract is published via the API Gateway outwards. The basic idea is that the data definition is fixed and standardized, and that requesting application will adapt their request to this definition. In that sense the API Gateway offers standardization in the landscape
36 36  * **Technical disqualifiers**
37 - ** For an API Gateway, the requestor needs to be able to call a REST based webservice using a supported messaging format
40 + ** For an API Gateway, the requestor needs to be able to call a REST based webservice using JSON formatted messages.
38 38   ** Messaging allows other web services such as SOAP, but can also handle XML for instance
39 39  * **Centralized User Management**
40 40   ** API gateway offers a easy to configure user management capability to protect operations. Users and roles can be designed in the Design phase, and various authentication methods are allowed such as OAuth2.0 and API Keys. eMagiz offers easy to use configurations for that
41 41   ** For Messaging, no such user management options exit and all needs to be created inside the flows that handle the requests & replies.
42 42  
43 -== 4. Key takeaways ==
46 +== 4. Assignment ==
44 44  
48 +There is no assignment for now in this microlearning
49 +
50 +== 5. Key takeaways ==
51 +
45 45  * There are a set of considerations to make decisions for API gateway vs. messaging
46 46  * Make sure to read the eMagiz Fundamentals properly before taking this section into account in your project
47 47  
48 -== 5. Suggested Additional Readings ==
55 +== 6. Suggested Additional Readings ==
49 49  
50 50  Take a moment to read the following [[Usecase>>doc:Main.eMagiz Academy.Use Cases.Pattern Determination.WebHome||target="blank"]]
51 51  
52 -)))((({{toc/}}))){{/container}}{{/container}}
59 +== 7. Silent demonstration video ==
60 +
61 +As this is a more theoretical microlearning, we have no video that accompanies this microlearning.)))((({{toc/}}))){{/container}}{{/container}}