Version 3.0.1 of a REST API implementation represents time values in PST time using ISO 8601 hh:mm:ss format. The API implementation needs to be changed to instead represent time values in CEST time using ISO 8601 hh:mm:ss format. When following the semver.org semantic versioning specification, what version should be assigned to the updated API implementation?
A.
3.0.2
B.
4.0.0
C.
3.1.0
D.
3.0.1
4.0.0
Explanation: Explanation
Correct Answer: 4.0.0
*****************************************
As per semver.org semantic versioning specification:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes.
- MINOR version when you add functionality in a backwards compatible manner.
- PATCH version when you make backwards compatible bug fixes.
As per the scenario given in the question, the API implementation is completely changing
its behavior. Although the format of the time is still being maintained as hh:mm:ss and there
is no change in schema w.r.t format, the API will start functioning different after this change
as the times are going to come completely different.
Example: Before the change, say, time is going as 09:00:00 representing the PST. Now on,
after the change, the same time will go as 18:00:00 as Central European Summer Time is
9 hours ahead of Pacific Time.
>> This may lead to some uncertain behavior on API clients depending on how they are
handling the times in the API response. All the API clients need to be informed that the API
functionality is going to change and will return in CEST format. So, this considered as a
MAJOR change and the version of API for this new change would be 4.0.0
An organization has created an API-led architecture that uses various API layers to integrate mobile clients with a backend system. The backend system consists of a number of specialized components and can be accessed via a REST API. The process and
experience APIs share the same bounded-context model that is different from the backend
data model. What additional canonical models, bounded-context models, or anti-corruption
layers are best added to this architecture to help process data consumed from the backend
system?
A.
Create a bounded-context model for every layer and overlap them when the boundary
contexts overlap, letting API developers know about the differences between upstream and
downstream data models
B.
Create a canonical model that combines the backend and API-led models to simplify
and unify data models, and minimize data transformations.
C.
Create a bounded-context model for the system layer to closely match the backend data
model, and add an anti-corruption layer to let the different bounded contexts cooperate
across the system and process layers
D.
Create an anti-corruption layer for every API to perform transformation for every data
model to match each other, and let data simply travel between APIs to avoid the complexity
and overhead of building canonical models
Create a bounded-context model for the system layer to closely match the backend data
model, and add an anti-corruption layer to let the different bounded contexts cooperate
across the system and process layers
Explanation: Explanation
Correct Answer: Create a bounded-context model for the system layer to closely match the
backend data model, and add an anti-corruption layer to let the different bounded contexts
cooperate across the system and process layers
*****************************************
>> Canonical models are not an option here as the organization has already put in efforts
and created bounded-context models for Experience and Process APIs.
>> Anti-corruption layers for ALL APIs is unnecessary and invalid because it is mentioned
that experience and process APIs share same bounded-context model. It is just the System
layer APIs that need to choose their approach now.
>> So, having an anti-corruption layer just between the process and system layers will work
well. Also to speed up the approach, system APIs can mimic the backend system data
model.
Which APIs can be used with DataGraph to create a unified schema?
A. APIs 1, 3, 5
B. APIs 2, 4 ,6
C. APIs 1, 2, s5, 6
D. APIs 1, 2, 3, 4
Explanation:
To create a unified schema in MuleSoft's DataGraph, APIs must be exposed
in a way that allows DataGraph to pull and consolidate data from these APIs into a single
schema accessible to consumers. DataGraph provides a federated approach, combining
multiple APIs to form a single, unified API endpoint.
In this setup:
APIs 1, 2, 3, and 4 are suitable candidates for DataGraph because they are hosted
within the Customer VPC on CloudHub and are accessible either through a
Shared Load Balancer (LB) or a Dedicated Load Balancer (DLB). Both of these
load balancers provide public access, which is a necessary condition for
DataGraph as it must access the APIs to aggregate data.
APIs 5 and 6 are hosted on Customer Hosted Server 2, which is explicitly marked
as "Not public". Since DataGraph requires API access through a publicly
reachable endpoint to aggregate them into a unified schema, APIs 5 and 6 cannot
be used with DataGraph in this configuration.
APIs 3 and 4 on Customer Hosted Server 1 appear accessible through a Shared
LB, implying public accessibility that meets DataGraph’s requirements.
By combining APIs 1, 2, 3, and 4 within DataGraph, you can create a unified schema that
enables clients to query data seamlessly from all these APIs as if it were from a single
source.
This setup allows for efficient data retrieval and can simplify API consumption by reducing
the need to call multiple APIs individually, thus optimizing performance and developer
experience.
An API has been updated in Anypoint exchange by its API producer from version 3.1.1 to
3.2.0 following accepted semantic versioning practices and the changes have been
communicated via the APIs public portal. The API endpoint does NOT change in the new
version. How should the developer of an API client respond to this change?
A.
The API producer should be requested to run the old version in parallel with the new one
B.
The API producer should be contacted to understand the change to existing functionality
C.
The API client code only needs to be changed if it needs to take advantage of the new features
D.
The API clients need to update the code on their side and need to do full regression
The API client code only needs to be changed if it needs to take advantage of the new features
When could the API data model of a System API reasonably mimic the data model
exposed by the corresponding backend system, with minimal improvements over the
backend system's data model?
A.
When there is an existing Enterprise Data Model widely used across the organization
B.
When the System API can be assigned to a bounded context with a corresponding data
model
C.
When a pragmatic approach with only limited isolation from the backend system is deemed appropriate
D.
When the corresponding backend system is expected to be replaced in the near future
When a pragmatic approach with only limited isolation from the backend system is deemed appropriate
Explanation: Explanation
Correct Answer: When a pragmatic approach with only limited isolation from the backend
system is deemed appropriate.
*****************************************
General guidance w.r.t choosing Data Models:
>> If an Enterprise Data Model is in use then the API data model of System APIs should
make use of data types from that Enterprise Data Model and the corresponding API
implementation should translate between these data types from the Enterprise Data Model
and the native data model of the backend system.
>> If no Enterprise Data Model is in use then each System API should be assigned to a
Bounded Context, the API data model of System APIs should make use of data types from
the corresponding Bounded Context Data Model and the corresponding API
implementation should translate between these data types from the Bounded Context Data
Model and the native data model of the backend system. In this scenario, the data types in
the Bounded Context Data Model are defined purely in terms of their business
characteristics and are typically not related to the native data model of the backend system.
In other words, the translation effort may be significant.
>> If no Enterprise Data Model is in use, and the definition of a clean Bounded Context
Data Model is considered too much effort, then the API data model of System APIs should
make use of data types that approximately mirror those from the backend system, same
semantics and naming as backend system, lightly sanitized, expose all fields needed for
the given System API’s functionality, but not significantly more and making good use of
REST conventions.
The latter approach, i.e., exposing in System APIs an API data model that basically mirrors
that of the backend system, does not provide satisfactory isolation from backend systems
through the System API tier on its own. In particular, it will typically not be possible to
"swap out" a backend system without significantly changing all System APIs in front of that
backend system and therefore the API implementations of all Process APIs that depend on
those System APIs! This is so because it is not desirable to prolong the life of a previous
backend system’s data model in the form of the API data model of System APIs that now
front a new backend system. The API data models of System APIs following this approach
must therefore change when the backend system is replaced.
On the other hand:
>> It is a very pragmatic approach that adds comparatively little overhead over accessing
the backend system directly
>> Isolates API clients from intricacies of the backend system outside the data model
(protocol, authentication, connection pooling, network address, …)
>> Allows the usual API policies to be applied to System APIs
>> Makes the API data model for interacting with the backend system explicit and visible,
by exposing it in the RAML definitions of the System APIs
>> Further isolation from the backend system data model does occur in the API
A Mule 4 API has been deployed to CloudHub and a Basic Authentication - Simple policy has been applied to all API methods and resources. However, the API is still accessible by clients without using authentication. How is this possible?
A. The APE Router component is pointing to the incorrect Exchange version of the APT
B. The Autodiscovery element is not present, in the deployed Mule application
C. No… for client applications have been created of this API
D. One of the application’s CloudHub workers restarted
Explanation:
When a Basic Authentication policy is applied to an API on CloudHub but
clients can still access the API without authentication, the likely cause is a missing
Autodiscovery element. Here’s how this affects API security:
In which layer of API-led connectivity, does the business logic orchestration reside?
A.
System Layer
B.
Experience Layer
C.
Process Layer
Process Layer
Explanation: Explanation
Correct Answer: Process Layer
*****************************************
>> Experience layer is dedicated for enrichment of end user experience. This layer is to
meet the needs of different API clients/ consumers.
>> System layer is dedicated to APIs which are modular in nature and implement/ expose
various individual functionalities of backend systems
>> Process layer is the place where simple or complex business orchestration logic is
written by invoking one or many System layer modular APIs
So, Process Layer is the right answer.
What are 4 important Platform Capabilities offered by Anypoint Platform?
A.
API Versioning, API Runtime Execution and Hosting, API Invocation, API Consumer Engagement
B.
API Design and Development, API Runtime Execution and Hosting, API Versioning, API
Deprecation
C.
API Design and Development, API Runtime Execution and Hosting, API Operations and
Management, API Consumer Engagement
D.
API Design and Development, API Deprecation, API Versioning, API Consumer
Engagement
API Design and Development, API Runtime Execution and Hosting, API Operations and
Management, API Consumer Engagement
Explanation: Explanation
Correct Answer: API Design and Development, API Runtime Execution and Hosting, API
Operations and Management, API Consumer Engagement
*****************************************
>> API Design and Development - Anypoint Studio, Anypoint Design Center, Anypoint
Connectors
>> API Runtime Execution and Hosting - Mule Runtimes, CloudHub, Runtime Services
>> API Operations and Management - Anypoint API Manager, Anypoint Exchange
>> API Consumer Management - API Contracts, Public Portals, Anypoint Exchange, API
Notebooks
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved