WEBVTT
00:00:11.820 --> 00:00:15.320
So the next session would be on Tuesday, right?
00:00:17.160 --> 00:00:21.320
Oh, actually, I've set up the Anypoint Studio and all in that specific desktops.
00:00:21.460 --> 00:00:23.000
I think we're good to go there exactly.
00:00:23.280 --> 00:00:23.800
Yeah.
00:00:23.820 --> 00:00:28.640
Actually, I am planning to use Zoom for sharing my screen.
00:00:28.640 --> 00:00:35.600
So I do have a couple of backgrounds to be drawn to explain the control flows and all.
00:00:35.920 --> 00:00:37.680
So I'll be using both of them, actually.
00:00:44.200 --> 00:00:45.840
Hi, Mark, how are you doing?
00:00:46.760 --> 00:00:49.100
Yeah. Yeah, I'm doing great.
00:00:50.800 --> 00:00:56.260
So first, let me just explain you a couple of things before we start.
00:00:56.260 --> 00:01:03.760
So basically, I'll be sharing my presentation with you and just going through the slides.
00:01:04.280 --> 00:01:08.160
That will be the primary information that I'm going to pass to you.
00:01:08.400 --> 00:01:11.240
And for explaining, I'll be using Pro.io.
00:01:11.660 --> 00:01:17.500
So basically, that's a kind of whiteboard application where I'll be drawing out
00:01:18.560 --> 00:01:24.080
a couple of workflows and control flows, how exactly things go in MuleSoft and all.
00:01:24.080 --> 00:01:25.760
So that would be one.
00:01:26.240 --> 00:01:28.400
And regarding the topics.
00:01:28.500 --> 00:01:32.420
So here we have a couple of topics in the course outline, right?
00:01:33.220 --> 00:01:39.940
So they are designed under specific pointers and placed under a header, right?
00:01:40.000 --> 00:01:43.140
Let's say for getting started, we do have preparing the development environment
00:01:43.140 --> 00:01:46.700
and API directories and navigating throughout the Anypoint platform.
00:01:46.920 --> 00:01:54.060
And also, I'll be just going through these pointers, but not in a straight way.
00:01:54.080 --> 00:01:57.960
So I'll be jumping here and jumping there.
00:01:58.560 --> 00:02:01.580
So it's like a mix and match of here and there.
00:02:01.840 --> 00:02:05.100
But I'll be covering all of them so that we'll be having a context
00:02:06.300 --> 00:02:09.160
from what exactly the point is and how to start.
00:02:10.320 --> 00:02:11.580
So, yeah, I'll share my screen.
00:02:12.320 --> 00:02:13.700
Let me know if it is visible to you.
00:02:16.520 --> 00:02:21.320
OK, so let me just give you a brief introduction.
00:02:21.320 --> 00:02:24.760
I hope you already know about MuleSoft, why it is used.
00:02:25.620 --> 00:02:29.400
I'll just give you, yeah.
00:02:30.040 --> 00:02:32.840
We'll be using MuleSoft to integrate
00:02:34.680 --> 00:02:38.100
APIs. So let's say there are two or three applications
00:02:38.100 --> 00:02:41.480
specific business is using.
00:02:41.880 --> 00:02:44.700
Let's say a business has its workflows
00:02:45.680 --> 00:02:49.980
specifically for logging in user or logging in administrators
00:02:49.980 --> 00:02:53.380
or that is one of the workflow, you can say,
00:02:53.440 --> 00:02:56.020
for using for logging in purposes.
00:02:56.440 --> 00:03:00.320
And you have catalogs of the product catalog, you can say.
00:03:01.040 --> 00:03:04.000
And the APS related to those catalogs, let's say,
00:03:04.200 --> 00:03:07.400
add a product or delete a product or modify a product.
00:03:07.780 --> 00:03:11.120
So of course, related to that specific product implementation.
00:03:11.500 --> 00:03:13.140
Let's say you have delivery.
00:03:13.760 --> 00:03:18.080
So let's say user order a product and you will be tracking the delivery
00:03:18.080 --> 00:03:21.900
and marking to marking whether the delivery has happened
00:03:21.900 --> 00:03:24.300
or it just came around.
00:03:24.720 --> 00:03:26.940
So workflows related to delivery aspects.
00:03:27.200 --> 00:03:28.920
So we'll be having a headers.
00:03:30.580 --> 00:03:32.640
Each and every organization has its,
00:03:32.640 --> 00:03:36.540
you know, control spread across different, different implementations,
00:03:36.960 --> 00:03:39.280
whether that might be a specific product catalog
00:03:39.280 --> 00:03:43.520
or whether that might be a product or specific implementation aspects
00:03:43.520 --> 00:03:48.900
or delivery aspects or management of data behind the scenes
00:03:48.900 --> 00:03:52.380
where customers are not, you know, easily interacting with whether
00:03:52.380 --> 00:03:55.600
I mean, customers even don't know whether we are, you know,
00:03:56.440 --> 00:03:58.060
managing the data behind the scenes.
00:03:58.060 --> 00:04:00.080
So for all these purposes, we do have different,
00:04:00.120 --> 00:04:04.720
different APIs integrated with them in order to integrate.
00:04:05.080 --> 00:04:08.480
I mean, in order to communicate between system and system communication,
00:04:08.800 --> 00:04:10.400
various system and system communication.
00:04:10.400 --> 00:04:14.880
I do mean, let's say,
00:04:14.880 --> 00:04:17.200
wanted to have a couple of web applications
00:04:17.200 --> 00:04:19.360
which are running doing a specific job,
00:04:20.620 --> 00:04:25.720
whether that job might be front end user based applications.
00:04:27.280 --> 00:04:28.560
Let's say a.
00:04:30.860 --> 00:04:34.060
You know, user interface applications
00:04:34.820 --> 00:04:38.940
like shopping applications or, you know, mobile applications or
00:04:38.940 --> 00:04:42.800
these are applications which are user interfacing applications user.
00:04:43.060 --> 00:04:45.360
I mean, the end user or the customers directly contract
00:04:45.360 --> 00:04:48.580
contact with the system by the help of these applications.
00:04:48.800 --> 00:04:54.280
And we have backdoor applications where analytics people will work on them.
00:04:54.380 --> 00:04:56.780
Let's say we do have a business and the team
00:04:57.320 --> 00:05:00.380
which mostly work on the data that is being produced
00:05:00.900 --> 00:05:02.440
by the front end applications.
00:05:02.900 --> 00:05:07.200
And we'll be doing and gathering the insights from those data.
00:05:07.200 --> 00:05:09.620
So this is a back end application.
00:05:10.080 --> 00:05:12.920
I mean, the end users and your end customers,
00:05:14.180 --> 00:05:17.060
you, I mean, by the word you, I mean, the company's end users
00:05:17.060 --> 00:05:21.480
or end customers will not be interacting with this end application.
00:05:21.920 --> 00:05:25.820
But this end application wants to interact with the user interface application.
00:05:26.200 --> 00:05:30.240
So this is like a typical scenario where we'll be using MuleSoft.
00:05:30.660 --> 00:05:35.100
So MuleSoft is a kind of middle man, you can say,
00:05:35.100 --> 00:05:39.260
which helps us integrating different, different
00:05:40.160 --> 00:05:45.440
applications, which are highly coupled when it comes to data
00:05:45.440 --> 00:05:47.900
or communication is concerned.
00:05:48.580 --> 00:05:51.380
So, I mean, so you're getting my point, right?
00:05:52.280 --> 00:05:54.640
Exactly. Yeah.
00:05:55.180 --> 00:05:58.340
So the word translator is fine
00:05:58.340 --> 00:06:02.480
as soon as it is on our human understanding.
00:06:02.480 --> 00:06:05.280
But let's say, but
00:06:05.280 --> 00:06:10.840
you need to have a specific way to encode and decode communication.
00:06:11.140 --> 00:06:14.100
Right. So that's where APS comes into picture.
00:06:14.540 --> 00:06:17.920
So in order to say in a layman language, basically,
00:06:19.000 --> 00:06:23.780
it takes care of APIs that is that is like inbound into MuleSoft
00:06:23.780 --> 00:06:28.280
and it provides them the outbound capabilities in order to, you know,
00:06:29.320 --> 00:06:31.520
have a couple of dumps
00:06:31.520 --> 00:06:36.440
where it wanted to dump data and other applications will be fetching data from there itself.
00:06:36.860 --> 00:06:40.140
So that's where it all fits into the ecosystem.
00:06:40.580 --> 00:06:44.880
So basically, it unifies the data for delivering a single view.
00:06:45.860 --> 00:06:49.960
So let's say you wanted to have all these applications that are managed in a
00:06:50.480 --> 00:06:55.360
single ecosystem or single environment so that customers or builds
00:06:55.360 --> 00:07:00.320
has, you know, collective experience or unified experience.
00:07:00.840 --> 00:07:07.500
And we don't want to kind of look out for each and for each and every automation process.
00:07:07.560 --> 00:07:09.540
We don't want to look out for any other tool.
00:07:09.880 --> 00:07:14.920
MuleSoft has it all tools integrated within itself so that we don't need to go for
00:07:14.920 --> 00:07:20.240
and check out for any other tool which is suitable for our end user implementations.
00:07:20.520 --> 00:07:25.860
So that is a deep introduction about MuleSoft and how it fits in the whole ecosystem.
00:07:26.340 --> 00:07:30.300
And when it comes to technology that MuleSoft is built on,
00:07:30.320 --> 00:07:36.040
so right now for all the MuleSoft developments and deployments,
00:07:36.320 --> 00:07:37.780
they're done on top of Java.
00:07:38.320 --> 00:07:43.520
So basically, right now, the latest version of MuleSoft that is being implemented,
00:07:43.720 --> 00:07:49.260
it's on Java 17, but initially the long term support is there for Java 8.
00:07:49.820 --> 00:07:55.760
So MuleSoft started its journey with Java 8 and it is being built on JVM implementations.
00:07:56.080 --> 00:07:59.660
When I say JVM, to give you a brief introduction about JVM,
00:07:59.660 --> 00:08:01.600
it's like Java virtual machine.
00:08:01.600 --> 00:08:08.940
So whenever you create Java applications or Java machines or
00:08:09.840 --> 00:08:14.020
Java enterprise servers or anything which are written on Java,
00:08:14.240 --> 00:08:17.440
they need to have a runtime environment where they need to run right.
00:08:17.700 --> 00:08:20.780
So that is provided by Java runtime environment.
00:08:21.060 --> 00:08:23.460
And we do have Java development kit.
00:08:23.700 --> 00:08:27.820
So basically, in order to deploy a MuleSoft application or in order to
00:08:27.820 --> 00:08:31.620
develop a MuleSoft application or in order to test a MuleSoft application,
00:08:31.780 --> 00:08:34.340
we need to have, compulsorily, we need to have Java.
00:08:34.460 --> 00:08:38.340
So it's like a prerequisite, but will not be highly interacting
00:08:38.340 --> 00:08:41.600
with the Java and it will be done by MuleSoft itself under the code.
00:08:42.040 --> 00:08:45.120
So you will not have any interaction with Java and there is no,
00:08:45.160 --> 00:08:49.200
not at all expectation for you to understand Java or anything.
00:08:49.360 --> 00:08:52.260
But if you want to have, you know,
00:08:53.540 --> 00:08:59.080
hiring or, you know, hiring people based on MuleSoft,
00:08:59.260 --> 00:09:03.680
having understanding on a little bit on Java would be giving them,
00:09:03.680 --> 00:09:08.520
you know, a point to understand where things goes on,
00:09:08.680 --> 00:09:11.820
how the control flow happens and how, you know,
00:09:12.920 --> 00:09:17.000
the things goes from one point to other point inside the MuleSoft.
00:09:17.280 --> 00:09:19.900
So that's where it hits on whole ecosystem basically.
00:09:20.500 --> 00:09:25.260
And, but how exactly things are built on MuleSoft.
00:09:25.680 --> 00:09:30.940
So let's say what is exactly the development environment for MuleSoft.
00:09:31.180 --> 00:09:35.800
So that is called MulePoint or MuleStudio basically we call that.
00:09:36.240 --> 00:09:39.900
And for MuleSoft, it's basically, initially,
00:09:41.040 --> 00:09:43.680
it's a kind of open source implementation tool,
00:09:44.100 --> 00:09:46.100
but later on Salesforce has taken that up.
00:09:46.920 --> 00:09:49.880
Like initially Java is an open source tool, but later on,
00:09:49.880 --> 00:09:52.780
Oracle takes that right. So similarly,
00:09:53.320 --> 00:09:55.600
MuleSoft is started its journey as an open source tool.
00:09:56.000 --> 00:09:57.980
And later on Salesforce has took that.
00:09:58.140 --> 00:10:03.040
And initially we do have any point studio as integrated development
00:10:03.040 --> 00:10:06.660
environment. We call that ITC, right? So initially we have that,
00:10:06.980 --> 00:10:10.080
but later on when Salesforce took the MuleSoft,
00:10:10.300 --> 00:10:13.320
it transformed its journey to any point studio platform.
00:10:13.740 --> 00:10:17.660
So this is a kind of, if you are aware of Azure,
00:10:17.660 --> 00:10:21.280
Microsoft Azure or AWS, are you aware of them?
00:10:21.920 --> 00:10:24.280
So basically we do have a portal, right?
00:10:24.540 --> 00:10:26.880
Where people go on,
00:10:27.240 --> 00:10:31.500
he just spin up the virtual machine with the help of his credentials and back
00:10:32.120 --> 00:10:36.060
things get delivered to him with the help of a web interface.
00:10:36.400 --> 00:10:40.460
So that's what this any point studio is. Like to sum up this,
00:10:40.600 --> 00:10:45.440
basically any point studio provides you much more similar to what
00:10:45.440 --> 00:10:49.300
Azure provides you, but it is on Microsoft Azure, but this is on,
00:10:49.300 --> 00:10:52.840
you'll see that stuff pretty much depends what we have.
00:10:53.420 --> 00:10:57.640
So any point studio itself is a development environment where developer
00:10:57.640 --> 00:11:01.400
comes on, he creates connectors, or he creates,
00:11:03.840 --> 00:11:06.100
like the pallets or canvas,
00:11:06.100 --> 00:11:10.180
and he creates these mule pallets and integrate
00:11:12.100 --> 00:11:15.420
implementations with the help of any point studio. I'll be, you know,
00:11:15.420 --> 00:11:20.080
walking through, walking you through this any point studio in later on sessions,
00:11:20.120 --> 00:11:26.080
but that is kind of a brief introduction about that. And yeah.
00:11:26.860 --> 00:11:29.820
And how exactly it works basically, MuleSoft.
00:11:30.020 --> 00:11:34.640
So when we have different developers or let's say,
00:11:35.000 --> 00:11:38.680
you're working on such system where you want to deliver your compute
00:11:38.680 --> 00:11:40.600
capabilities in terms of APIs,
00:11:40.980 --> 00:11:45.160
let's say you are having that specific use case and you want it to have
00:11:45.160 --> 00:11:49.580
great limits for your API so that you want it to deliver, let's say,
00:11:49.660 --> 00:11:54.540
you want for your clients such that the clients are entitled to hit this
00:11:54.540 --> 00:11:56.660
API only 2,500 times per day.
00:11:56.900 --> 00:12:01.760
So you want to have this all complex mechanisms built on top of your
00:12:01.760 --> 00:12:05.640
application so that you don't want to maintain that maintain these,
00:12:05.640 --> 00:12:10.240
you know, custom integrations and all these examples that I provided,
00:12:10.240 --> 00:12:13.180
right? So basically you wanted to have great limit implementations,
00:12:13.180 --> 00:12:19.000
or you wanted to have a different API keys where you want to onboard
00:12:19.000 --> 00:12:21.040
different, different users on a single tenant.
00:12:21.420 --> 00:12:25.560
So that is one of the use case where you want to integrate MuleSoft so
00:12:25.560 --> 00:12:30.060
that you'll be delivering a single platform to different users so that you
00:12:30.060 --> 00:12:32.820
can build out of them or you can, you know,
00:12:33.020 --> 00:12:37.780
scale things much more easily without any much headache or
00:12:37.780 --> 00:12:39.100
scaling and other aspects.
00:12:39.280 --> 00:12:42.120
So MuleSoft takes care of all those things,
00:12:42.120 --> 00:12:44.200
which are built on top of API implementations.
00:12:45.200 --> 00:12:48.480
So that's how MuleSoft sits in whole ecosystem.
00:12:49.360 --> 00:12:50.880
So you have any questions till now?
00:12:52.760 --> 00:12:59.160
So let's go our discussion to MuleSoft Anypoint as I've already told you.
00:12:59.560 --> 00:13:04.740
So this MuleSoft Anypoint platform is like a single solution where you
00:13:04.740 --> 00:13:08.160
can deliver things within a web application.
00:13:08.680 --> 00:13:09.160
That's all.
00:13:09.200 --> 00:13:10.440
You don't need to install anything.
00:13:10.440 --> 00:13:11.300
You don't need to have.
00:13:11.300 --> 00:13:16.640
So I told it for MulePoint Studio, it's an IDE and you need to have all
00:13:16.640 --> 00:13:19.940
the setup already done in your local environment.
00:13:20.300 --> 00:13:22.880
So you need to have Java Virtual Machine installed.
00:13:23.180 --> 00:13:26.960
You need to have Java Development Kit installed and you need to have at
00:13:26.960 --> 00:13:32.760
least 10 gigs of RAM inside your machine and you need to have at
00:13:32.760 --> 00:13:34.980
least 500 GB of hard disk installed in your machine.
00:13:35.220 --> 00:13:39.200
So these are like prerequisites that you want to run MuleStudio,
00:13:39.200 --> 00:13:44.400
but that would be difficult for an administrator who doesn't want to
00:13:44.400 --> 00:13:47.100
develop things, but he wants to have control over things.
00:13:47.780 --> 00:13:51.560
So that's where this MuleSoft Anypoint comes into picture.
00:13:52.100 --> 00:13:57.280
So it gives us, I mean, it gives a person, an administrator or a
00:13:57.800 --> 00:13:59.040
development person as well.
00:13:59.280 --> 00:14:04.200
When I say development person, a developer or integrating person or,
00:14:05.120 --> 00:14:06.640
you know, APS specialist.
00:14:06.640 --> 00:14:11.860
When I say APS specialist, a person who controls the deployments of
00:14:11.860 --> 00:14:18.520
APIs or a person who implements user onboarding or those aspects of
00:14:19.360 --> 00:14:23.920
the MuleSoft implementation, this will be the, I mean, this Anypoint
00:14:23.920 --> 00:14:27.680
will be like a go-to solution for them instead of having all the
00:14:27.680 --> 00:14:29.000
local setup done and all.
00:14:29.280 --> 00:14:31.580
So this will be an easy solution.
00:14:32.300 --> 00:14:38.980
And it provides you, like, let's say you have this all packaged
00:14:38.980 --> 00:14:42.720
MuleSoft application and you wanted to kind of run this specific
00:14:42.720 --> 00:14:46.000
packaged MuleSoft application, which is delivered by your developers
00:14:46.000 --> 00:14:47.880
and you wanted to test it out.
00:14:48.120 --> 00:14:54.160
So let's say you have different, different teams inside your project
00:14:54.160 --> 00:14:57.420
and you have developers team, you have your testers team, and
00:14:57.420 --> 00:14:59.120
you have your deployment team.
00:14:59.120 --> 00:15:04.660
So you wanted to have this difference of responsibilities within
00:15:04.660 --> 00:15:06.000
each and every person.
00:15:06.960 --> 00:15:11.100
So, but let's say developers developed an implementation or a
00:15:11.100 --> 00:15:13.980
MuleSoft application or an application code.
00:15:14.660 --> 00:15:19.100
And they, you know, build that code and exported that code as a
00:15:19.100 --> 00:15:20.140
part of JAR Artifact.
00:15:20.400 --> 00:15:24.440
And you wanted to gather this specific JAR Artifact and provide
00:15:24.440 --> 00:15:27.720
this JAR Artifact to the testers team where you want to test
00:15:27.720 --> 00:15:28.540
the applications.
00:15:28.540 --> 00:15:33.560
So they need, they don't need to have any implementation details
00:15:33.560 --> 00:15:34.820
where developers worked on.
00:15:35.160 --> 00:15:42.580
So it's like a difference of implementations or a difference
00:15:42.580 --> 00:15:49.240
between, you wanted to have varied responsibilities within
00:15:49.240 --> 00:15:52.000
each and every team, but you wanted to keep them integrated.
00:15:53.000 --> 00:15:56.180
So on those scenarios, MuleSoft, any point comes into picture.
00:15:56.700 --> 00:15:57.480
So you got, right.
00:15:57.480 --> 00:16:00.860
So basically different, different implementation teams,
00:16:01.180 --> 00:16:03.400
but they wanted to work on the same project.
00:16:04.260 --> 00:16:08.760
Parallelly in those scenarios, MuleSoft, any point team, I mean
00:16:08.760 --> 00:16:12.740
MuleSoft, any point application comes into picture, but we don't
00:16:12.740 --> 00:16:15.960
have that, you know, luxury with any point studio.
00:16:16.400 --> 00:16:19.440
Any point studio is like a local runtime environment, you
00:16:19.440 --> 00:16:23.360
can say, where things will be easy for local development and
00:16:23.360 --> 00:16:26.980
local testing, but that's not the way the current organizations
00:16:26.980 --> 00:16:28.780
or current businesses work on.
00:16:29.140 --> 00:16:33.120
It's like current businesses should have, things should be
00:16:33.120 --> 00:16:34.700
going on to production within it.
00:16:35.520 --> 00:16:38.220
Once it is developed and once it is tested, we don't want to
00:16:38.980 --> 00:16:40.440
have big bank releases, right?
00:16:41.400 --> 00:16:42.300
So that is the thing.
00:16:42.400 --> 00:16:44.280
And we also have this unit testing framework
00:16:44.280 --> 00:16:46.120
inside MuleSoft, any point.
00:16:46.540 --> 00:16:47.500
So I'll be showing you all of this.
00:16:48.720 --> 00:16:52.980
Feel free to stop me if you think anything is lagging or,
00:16:53.240 --> 00:16:56.060
you know, you don't want to understand.
00:16:56.060 --> 00:17:01.160
So when we want to navigate quickly between any point platform,
00:17:01.300 --> 00:17:03.560
so we have this couple of things here.
00:17:03.700 --> 00:17:05.000
So you can see, right?
00:17:05.100 --> 00:17:06.200
Any point code builder.
00:17:06.440 --> 00:17:10.680
So it's basically, it's a new feature right now inside any point
00:17:10.680 --> 00:17:12.380
platform, it's on beta stage right now.
00:17:13.340 --> 00:17:16.960
So I don't think it's better to discuss this right now, but
00:17:16.960 --> 00:17:18.320
I'll give you a brief idea over this.
00:17:18.440 --> 00:17:21.060
So right now, as I have told you, right?
00:17:21.280 --> 00:17:25.700
So this any point studio, it has a couple of, not couple, it has
00:17:25.700 --> 00:17:31.380
a lot of downsides right now, and it has a lot of cons
00:17:31.380 --> 00:17:33.720
rather than any point platform.
00:17:33.960 --> 00:17:38.960
So this any point code builder, it's like an integration tool that is being
00:17:38.960 --> 00:17:42.100
developed inside the any point platform itself as a separate
00:17:43.600 --> 00:17:45.100
implementation or separate.
00:17:46.960 --> 00:17:51.580
Right now, if you see here, it's the API manager itself has a different route.
00:17:51.760 --> 00:17:54.740
So whatever you are doing inside this API manager,
00:17:55.220 --> 00:17:59.100
it's on the same any point platform, but the look and feel will be
00:17:59.100 --> 00:18:01.360
same and the single sign on will be same.
00:18:01.420 --> 00:18:04.840
You don't need to have different, different credentials to work on and all.
00:18:05.840 --> 00:18:10.320
So similarly, the any point code builder is like tight integration
00:18:10.320 --> 00:18:11.460
with the any point platform.
00:18:11.620 --> 00:18:16.080
You can say where we don't need to use any point studio anymore.
00:18:16.420 --> 00:18:20.660
Developer can do workflows, designing and workflows,
00:18:20.660 --> 00:18:26.260
implementations or workflows, testing and giving mocking requests
00:18:26.260 --> 00:18:29.620
to the workflow and all with the help of just code builder.
00:18:29.660 --> 00:18:32.720
We don't need to learn about any point studio anymore.
00:18:33.180 --> 00:18:36.680
Once this is, I mean, the development of code builder is completed
00:18:36.680 --> 00:18:39.360
and people are good to use this code builder.
00:18:39.700 --> 00:18:41.360
So yeah, this is the API manager.
00:18:42.660 --> 00:18:45.980
So you could able to see which screen right now.
00:18:45.980 --> 00:18:47.240
Good. Yeah.
00:18:47.700 --> 00:18:53.060
So this API manager, it's like go to solution where you want to create
00:18:53.060 --> 00:18:57.120
an API and deploy that API for deployment.
00:18:57.440 --> 00:19:07.000
We have this any point exchange or any point runtime manager
00:19:07.000 --> 00:19:09.460
where we'll be deploying our APIs.
00:19:09.880 --> 00:19:13.440
But when it comes to designing an API, so let's say I have
00:19:13.440 --> 00:19:21.140
already created, you can see the metrics that the specific API
00:19:21.140 --> 00:19:22.720
that is being deployed over here.
00:19:23.180 --> 00:19:26.720
So let's say you wanted to see a specific implementations.
00:19:26.940 --> 00:19:34.480
Let's say so this any point API platform like this API
00:19:34.480 --> 00:19:40.320
administrator provides us tools to choose the runtime environment.
00:19:40.520 --> 00:19:42.280
Here we are using Mule 4 as our runtime.
00:19:42.280 --> 00:19:46.280
So I have developed this specific product API with the help of Mule 4.
00:19:47.120 --> 00:19:50.820
I'll show that how we'll be doing that inside the any point studio
00:19:50.820 --> 00:19:54.840
in later classes and the version that we are using
00:19:55.440 --> 00:20:00.880
and the instance that we deployed the specific API
00:20:00.880 --> 00:20:05.000
and what's the error that we got and how many test requests
00:20:05.000 --> 00:20:06.120
that it is being hit.
00:20:07.060 --> 00:20:10.220
So right now it's like no one has access to this.
00:20:10.220 --> 00:20:12.680
Let's say I push this into production environment
00:20:12.680 --> 00:20:16.740
and things goes wrong in few scenarios.
00:20:17.300 --> 00:20:23.620
So in those scenarios we'll be having metrics and policies
00:20:23.620 --> 00:20:27.540
that we want to enforce inside this specific implementation.
00:20:27.900 --> 00:20:32.520
So that's how this API manager works.
00:20:32.740 --> 00:20:35.920
We'll be going through these in later like the detailed
00:20:35.920 --> 00:20:39.500
things in later classes and when it comes to API governance.
00:20:39.500 --> 00:20:44.160
So this API governance basically provides us a couple of policies
00:20:44.160 --> 00:20:46.100
where we want to define these policies.
00:20:46.220 --> 00:20:49.860
Let's say you're working on some European based projects
00:20:49.860 --> 00:20:53.780
and in European based projects you will be having a strict
00:20:53.780 --> 00:20:57.800
data management policies where you wanted to keep specific
00:20:59.680 --> 00:21:03.820
customers data for only a specified period of time
00:21:03.820 --> 00:21:07.140
and you wanted to erase that completely the hard erasing
00:21:07.140 --> 00:21:09.300
you can say not the soft erasing and all.
00:21:09.300 --> 00:21:12.480
So you have to make your platform or application
00:21:12.480 --> 00:21:15.180
that is being developed on top of this platform
00:21:15.180 --> 00:21:19.780
complying to all these policies that is being pushed
00:21:19.780 --> 00:21:22.920
by government organizations or agencies.
00:21:23.000 --> 00:21:24.580
We'll be using this API governance.
00:21:24.580 --> 00:21:28.800
So basically it's a kind of policy management platform
00:21:28.800 --> 00:21:31.840
you can say in a simple word so that you can create
00:21:31.840 --> 00:21:36.100
policies and enforce those policies on platform
00:21:36.100 --> 00:21:37.980
that you are working on basically.
00:21:37.980 --> 00:21:39.740
So that is the API governance.
00:21:40.340 --> 00:21:43.560
So basically this will be used for matured projects
00:21:44.380 --> 00:21:47.160
not for sandbox environment projects or not for
00:21:47.160 --> 00:21:49.760
development projects or not for testing environments.
00:21:50.420 --> 00:21:52.420
Basically it's for already deployed projects
00:21:52.420 --> 00:21:56.000
and they are in a production load production like systems
00:21:56.000 --> 00:22:01.680
and the people who are using these projects or platform
00:22:01.680 --> 00:22:05.040
is also matters for this specific API governance.
00:22:05.340 --> 00:22:07.460
I mean if you want to use this API governance
00:22:07.460 --> 00:22:11.300
then people from where they vote are using this
00:22:12.120 --> 00:22:14.620
application also matters basically for this.
00:22:14.720 --> 00:22:17.880
So it's like more mature for more mature projects
00:22:17.880 --> 00:22:20.680
and this runtime manager as I've told you right.
00:22:20.920 --> 00:22:23.840
So let's say you have developed your application
00:22:23.840 --> 00:22:26.560
new application we call applications that are
00:22:26.560 --> 00:22:28.800
developed inside new soft as new applications.
00:22:29.860 --> 00:22:33.300
So let's say you you means your developers worked on
00:22:34.880 --> 00:22:39.040
new soft and they created a separate artifact
00:22:39.040 --> 00:22:41.600
which is a result of the development effort
00:22:41.600 --> 00:22:42.300
that they have put.
00:22:42.580 --> 00:22:44.260
So you wanted to deploy this artifact.
00:22:44.760 --> 00:22:46.920
So you in the sense a person who manages
00:22:46.920 --> 00:22:48.660
the instance of the application.
00:22:49.180 --> 00:22:52.640
So basically the job roles inside this new soft
00:22:52.640 --> 00:22:54.800
endpoint I mean in this new soft ecosystem
00:22:54.800 --> 00:22:57.780
they revolve around this is kind of bit of topic
00:22:57.780 --> 00:23:00.780
but if you wanted to understand like how things
00:23:00.780 --> 00:23:03.920
goes on in huge organizations where the separation
00:23:03.920 --> 00:23:05.360
of concern is present right.
00:23:05.520 --> 00:23:09.060
So developers works on only API implementations
00:23:09.060 --> 00:23:11.320
and testing team will be working on only
00:23:11.320 --> 00:23:14.700
the testing teams and deployment or set
00:23:14.700 --> 00:23:17.880
level to engineers they work mostly on creating
00:23:17.880 --> 00:23:19.920
continuous integrations and continuous deployments
00:23:19.920 --> 00:23:23.360
for the new applications and making sure that
00:23:23.360 --> 00:23:25.800
the uptime metrics are passing for them.
00:23:25.800 --> 00:23:27.620
So basically this center metric
00:23:27.620 --> 00:23:30.680
and the manager is mostly used by development guys
00:23:31.820 --> 00:23:34.420
or what we call set label team engineers.
00:23:34.960 --> 00:23:39.980
So those people mostly use this runtime manager.
00:23:40.160 --> 00:23:42.060
So we have this couple of pains here.
00:23:42.320 --> 00:23:45.840
So basically each and every pain responsible
00:23:45.840 --> 00:23:48.340
for its own deployment aspect.
00:23:48.380 --> 00:23:52.340
So let's say I so you have this test application
00:23:52.340 --> 00:23:54.840
and it is deployed under cloud hub.
00:23:54.840 --> 00:23:57.880
So basically cloud hub is a one stop solution
00:23:57.880 --> 00:24:00.500
for your deployment efforts inside
00:24:02.940 --> 00:24:03.860
any platform.
00:24:03.980 --> 00:24:06.860
So it's like we have this separate session
00:24:06.860 --> 00:24:09.700
to talk about how to deploy things inside cloud hub
00:24:09.700 --> 00:24:12.560
but it's a kind of target cloud you can say
00:24:12.560 --> 00:24:14.480
so that you can just deploy this
00:24:14.480 --> 00:24:16.260
and share the URL with the others
00:24:16.260 --> 00:24:18.720
so that any person who is on cloud
00:24:18.720 --> 00:24:21.180
can just utilize this I mean any person
00:24:21.180 --> 00:24:23.420
who is on globe you just utilize that
00:24:23.420 --> 00:24:26.560
and consume this API with the help of credentials
00:24:26.560 --> 00:24:28.680
that you have provided and the URL that you have provided.
00:24:29.740 --> 00:24:32.400
So basically the deployment model
00:24:32.400 --> 00:24:34.800
I mean we can also define the deployment model here.
00:24:34.960 --> 00:24:36.960
So we have this couple of deployment models
00:24:36.960 --> 00:24:39.000
like a cloud hub deployment model.
00:24:39.000 --> 00:24:40.560
It is one kind of deployment model
00:24:40.560 --> 00:24:44.340
or let's say you have your own servers
00:24:44.340 --> 00:24:45.900
like the on-premise servers
00:24:45.900 --> 00:24:49.500
and you wanted to maintain all your networking related
00:24:49.500 --> 00:24:52.540
concepts over there or policies over there
00:24:52.540 --> 00:24:56.100
the network policies and compute resources
00:24:56.100 --> 00:24:58.300
that you have inside your on-premise.
00:24:58.360 --> 00:25:00.580
So basically you wanted to have your own
00:25:00.580 --> 00:25:03.700
user managed platform
00:25:03.700 --> 00:25:05.880
but you wanted to integrate this on-premise
00:25:05.880 --> 00:25:06.820
to the runtime manager.
00:25:07.080 --> 00:25:08.840
So let's say you have five or six APS
00:25:08.840 --> 00:25:11.240
that is being delivered to your clients
00:25:11.880 --> 00:25:14.980
and you don't want to deploy all these five solutions
00:25:14.980 --> 00:25:17.240
but you wanted to manage all these five solutions
00:25:17.240 --> 00:25:20.760
inside any one platform so that you have a holistic
00:25:20.760 --> 00:25:23.320
you know I mean just you wanted to use
00:25:24.080 --> 00:25:27.380
for metrics purpose this Anypoint platform
00:25:27.380 --> 00:25:30.020
but for deployment purpose and for storage purpose
00:25:30.020 --> 00:25:33.720
you wanted to use your on-premise environments.
00:25:33.720 --> 00:25:37.760
You can just like integrate this any deployment model
00:25:37.760 --> 00:25:39.760
and connect your on-premise servers
00:25:39.760 --> 00:25:41.620
to this Anypoint platform
00:25:41.620 --> 00:25:43.620
and you can just utilize that.
00:25:43.880 --> 00:25:44.860
So you got my point right.
00:25:44.960 --> 00:25:47.220
So you can just grab the things
00:25:47.220 --> 00:25:48.600
that are being deployed in Open
00:25:49.560 --> 00:25:51.480
like your on-premise servers and just
00:25:52.140 --> 00:25:53.900
it's kind of lift and shift mechanism
00:25:53.900 --> 00:25:56.880
you wanted to manage everything under a single head.
00:25:57.340 --> 00:25:58.760
So that's how it works
00:25:58.760 --> 00:26:02.060
and you also have this flex gateways basically
00:26:02.060 --> 00:26:03.800
this flex gateways are like
00:26:05.340 --> 00:26:09.600
let's say you have your application deployed
00:26:09.600 --> 00:26:11.640
inside this cloud hub
00:26:11.640 --> 00:26:16.160
and you don't want to provide your URL
00:26:16.160 --> 00:26:18.140
to the end users.
00:26:18.140 --> 00:26:20.460
So let's say you're having a price model
00:26:21.060 --> 00:26:25.440
let's say you wanted to serve this specific APA
00:26:25.440 --> 00:26:28.400
for only those clients who have subs subscribed
00:26:28.400 --> 00:26:30.280
for your subscription
00:26:30.280 --> 00:26:34.520
and you wanted to have more secure way
00:26:34.520 --> 00:26:37.120
of providing this I mean delivering this API.
00:26:37.320 --> 00:26:38.480
So in those scenarios
00:26:38.480 --> 00:26:40.340
you will be deploying a single tenant
00:26:40.340 --> 00:26:43.720
and just separating each and every user
00:26:43.720 --> 00:26:44.540
inside this tenant.
00:26:44.780 --> 00:26:46.980
So you don't want to have a single URL
00:26:46.980 --> 00:26:49.820
and just distribute this URL to each and everyone
00:26:49.820 --> 00:26:52.700
because that provides security to the application.
00:26:52.700 --> 00:26:55.300
So you wanted to have separation of concern
00:26:55.300 --> 00:26:58.160
in terms of gateways
00:26:58.160 --> 00:27:02.600
or the deployments that you have done
00:27:02.600 --> 00:27:04.300
so that you will be having
00:27:04.300 --> 00:27:06.720
I mean you just deploy a specific gateway
00:27:06.720 --> 00:27:10.140
and let's say you have deployed it
00:27:10.140 --> 00:27:11.760
in a specific Kubernetes cluster
00:27:12.860 --> 00:27:15.180
and for each and every customer
00:27:15.180 --> 00:27:18.220
you will be creating a new endpoint
00:27:18.220 --> 00:27:19.620
so that you'll be delivering
00:27:19.620 --> 00:27:21.800
this only new endpoint for that customer
00:27:21.800 --> 00:27:24.260
and whenever let's say the customer
00:27:24.260 --> 00:27:26.200
don't want to continue his subscription
00:27:26.200 --> 00:27:29.620
you'll be having like granular control
00:27:29.620 --> 00:27:32.640
over what this customer can do
00:27:33.420 --> 00:27:34.560
inside your application.
00:27:34.580 --> 00:27:36.940
So basically it's like kind of limitation
00:27:36.940 --> 00:27:40.180
of providing limitations for deliveries
00:27:40.180 --> 00:27:42.320
for the API access basically
00:27:42.320 --> 00:27:44.060
you don't want to provide access
00:27:44.060 --> 00:27:45.720
I mean you want to stop the access
00:27:45.720 --> 00:27:48.020
for those API endpoints
00:27:48.020 --> 00:27:49.620
which you have created.
00:27:50.060 --> 00:27:53.500
So basically we'll be using these gateways
00:27:54.740 --> 00:27:56.700
or what we call the flexible gateways
00:27:56.700 --> 00:28:01.200
basically these are managed by the flex gateways
00:28:01.200 --> 00:28:04.480
this is a new concept in runtime manager
00:28:04.480 --> 00:28:06.300
which is in any point platform.
00:28:06.900 --> 00:28:09.820
So that's one of the use case what we call
00:28:09.820 --> 00:28:11.080
and allows and all
00:28:11.080 --> 00:28:12.340
so these are for production systems
00:28:12.860 --> 00:28:16.020
let's say you have these servers basically
00:28:16.020 --> 00:28:17.800
I did not explain this basically
00:28:17.800 --> 00:28:19.120
so you have these servers
00:28:19.120 --> 00:28:20.680
let's say you wanted to create a server
00:28:20.680 --> 00:28:23.340
and you wanted to provision this server
00:28:23.340 --> 00:28:24.760
let's say five gigs of RAM
00:28:24.760 --> 00:28:27.840
and there is a lot of traffic
00:28:27.840 --> 00:28:30.840
that is being provided to your API
00:28:30.840 --> 00:28:36.360
in huge like top-notch conditions
00:28:36.360 --> 00:28:37.940
let's say there is a sale going on
00:28:37.940 --> 00:28:38.720
for your application
00:28:38.720 --> 00:28:39.900
and there are lots of hits
00:28:39.900 --> 00:28:41.220
for your application
00:28:41.220 --> 00:28:45.000
you do not sign up for any auto scaling
00:28:45.000 --> 00:28:46.380
implementations for your servers
00:28:46.380 --> 00:28:47.680
so in those scenarios
00:28:47.680 --> 00:28:51.000
you don't want to give 500x responses
00:28:51.000 --> 00:28:51.580
for your clients.
00:28:51.960 --> 00:28:54.860
So that would be having bad implications
00:28:54.860 --> 00:28:57.800
or bad user experience for the clients
00:28:57.800 --> 00:28:59.500
so that you can just sign up
00:28:59.500 --> 00:29:00.020
for these alerts
00:29:00.020 --> 00:29:02.420
and these alerts basically provides you
00:29:02.420 --> 00:29:05.140
whenever there are
00:29:06.320 --> 00:29:08.960
I mean the actual threshold
00:29:08.960 --> 00:29:10.480
is being met for your servers
00:29:10.480 --> 00:29:12.700
then you will be having this alert
00:29:13.360 --> 00:29:16.420
to a specific implementation aspect
00:29:16.420 --> 00:29:20.300
let's say you have provided your mobile phone
00:29:20.300 --> 00:29:21.200
as one of the alerts
00:29:21.200 --> 00:29:22.360
or having a call
00:29:22.360 --> 00:29:23.400
or having an SMS
00:29:23.400 --> 00:29:26.060
or having a Slack notification
00:29:26.060 --> 00:29:27.520
or email notification anything
00:29:27.520 --> 00:29:31.000
we do have lots of DHCP configurations as well
00:29:31.000 --> 00:29:34.560
so let's say you have your own organization's email
00:29:34.560 --> 00:29:36.640
you don't want to integrate that
00:29:36.640 --> 00:29:38.440
with the sales force
00:29:38.440 --> 00:29:41.700
because of any security reasons
00:29:41.700 --> 00:29:44.280
you do have a couple of DHCP integrations
00:29:44.280 --> 00:29:45.060
for this alert
00:29:45.060 --> 00:29:48.400
it's a kind of very flexible system
00:29:48.960 --> 00:29:51.680
when compared to other API systems
00:29:51.680 --> 00:29:53.060
like Google APG
00:29:53.060 --> 00:29:54.560
or those platforms
00:29:54.560 --> 00:29:55.720
which are like rivalries
00:29:55.720 --> 00:29:58.000
for a new soft implementations
00:29:58.000 --> 00:30:00.600
and these are VPCs
00:30:00.600 --> 00:30:02.080
these are like out of point
00:30:02.080 --> 00:30:03.000
for discussion right now
00:30:03.000 --> 00:30:05.300
these are like more granular
00:30:07.740 --> 00:30:09.440
virtual private cloud basically
00:30:09.440 --> 00:30:12.000
these will provide you more granular access
00:30:12.000 --> 00:30:15.000
over which applications are being deployed
00:30:15.000 --> 00:30:17.260
what is the mechanism of networking
00:30:17.260 --> 00:30:18.960
that is being utilized and all
00:30:18.960 --> 00:30:21.000
so I don't think it's much required
00:30:21.000 --> 00:30:23.300
but you know the load balancers right
00:30:23.300 --> 00:30:25.640
so basically a typical load balancer
00:30:25.640 --> 00:30:28.340
provides you a kind of load balancing
00:30:28.340 --> 00:30:29.380
between different instances
00:30:29.380 --> 00:30:31.440
let's say you have opted for
00:30:32.460 --> 00:30:33.880
horizontal auto scaling
00:30:33.880 --> 00:30:34.980
in those scenarios
00:30:34.980 --> 00:30:39.100
new servers will be added to your deployment
00:30:39.100 --> 00:30:41.840
and you wanted to auto scale them
00:30:41.840 --> 00:30:44.880
but you don't have any single point of contact
00:30:44.880 --> 00:30:46.380
let's say each and every server
00:30:46.380 --> 00:30:48.960
has its own IP address associated with that
00:30:48.960 --> 00:30:51.460
but we don't want to provide each and every server
00:30:51.460 --> 00:30:52.600
to different different users
00:30:52.600 --> 00:30:54.320
that would be a different task
00:30:54.320 --> 00:30:55.560
and we want to
00:30:55.560 --> 00:30:57.180
I mean that would become very difficult
00:30:57.180 --> 00:30:59.360
to maintain in long run as well
00:30:59.360 --> 00:31:01.300
let's say you have 50 or 60 servers
00:31:01.300 --> 00:31:02.360
and you don't want to manage
00:31:02.360 --> 00:31:03.700
all of them manually
00:31:03.700 --> 00:31:06.160
then load balancers comes into picture
00:31:06.980 --> 00:31:08.840
so that is the thing
00:31:08.840 --> 00:31:11.800
so it's a kind of whole overview
00:31:11.800 --> 00:31:13.340
on the runtime manager
00:31:15.960 --> 00:31:18.340
and do you have any questions still now
00:31:23.560 --> 00:31:25.860
and this is a visualizer
00:31:26.380 --> 00:31:31.480
visualizer is a kind of application platform
00:31:31.480 --> 00:31:33.300
where you want to visualize
00:31:33.300 --> 00:31:36.980
how your network aspects are implemented
00:31:36.980 --> 00:31:38.960
or let's say you have created a VPC
00:31:38.960 --> 00:31:40.180
and you have deployed
00:31:40.180 --> 00:31:42.380
or tens or tens number of servers
00:31:42.380 --> 00:31:43.580
let's say you have deployed around
00:31:43.580 --> 00:31:44.660
25 or 30 servers
00:31:44.660 --> 00:31:47.060
and you wanted to understand
00:31:47.780 --> 00:31:49.700
how these communication takes place
00:31:51.380 --> 00:31:53.380
what are the user facing servers
00:31:53.380 --> 00:31:55.300
and what are backend servers
00:31:55.300 --> 00:31:58.500
which are accessible for only for our
00:31:59.560 --> 00:32:01.700
people who are directly interacting
00:32:01.700 --> 00:32:05.100
with our VPN being connected
00:32:05.100 --> 00:32:06.960
to the organizations VPN
00:32:06.960 --> 00:32:09.820
so it provides us a kind of
00:32:09.820 --> 00:32:11.300
simplified dashboards
00:32:11.300 --> 00:32:13.320
where we wanted to integrate
00:32:13.320 --> 00:32:14.580
our specific applications
00:32:15.780 --> 00:32:17.780
and like management aspects
00:32:17.780 --> 00:32:20.100
basically this visualizer provides us
00:32:20.100 --> 00:32:22.360
and this monitoring tools
00:32:22.360 --> 00:32:23.880
so basically let's say
00:32:23.880 --> 00:32:26.080
you have deployed a specific application
00:32:26.080 --> 00:32:27.060
inside the MuleSoft
00:32:27.060 --> 00:32:29.540
and you wanted to monitor
00:32:29.540 --> 00:32:30.720
that specific implementation
00:32:30.720 --> 00:32:36.040
let's say we do have these metrics and alerts
00:32:36.640 --> 00:32:38.260
so let's say you have
00:32:38.260 --> 00:32:39.580
I mean you've been using
00:32:40.180 --> 00:32:41.920
here we have lots of servers
00:32:41.920 --> 00:32:43.400
as we have seen earlier
00:32:43.400 --> 00:32:46.440
we have these lots of servers over here
00:32:46.440 --> 00:32:47.860
if you want to add a server
00:32:47.860 --> 00:32:50.920
you have a different way
00:32:50.920 --> 00:32:52.480
to add a server basically
00:32:53.040 --> 00:32:55.540
we have Kubernetes server
00:32:55.540 --> 00:32:56.940
and we have OpenShift server
00:32:56.940 --> 00:32:58.060
we have Linux server
00:32:58.060 --> 00:32:59.960
and a lot more servers
00:32:59.960 --> 00:33:02.600
so let's say for your use cases
00:33:02.600 --> 00:33:03.940
for one of your application
00:33:03.940 --> 00:33:05.660
you will be going for Kubernetes clusters
00:33:05.660 --> 00:33:07.420
and for one of your applications
00:33:07.420 --> 00:33:08.860
the architecture itself
00:33:08.860 --> 00:33:11.000
supports Linux-based implementations
00:33:11.000 --> 00:33:13.800
so like Kubernetes has its own
00:33:15.180 --> 00:33:16.720
matrix management system
00:33:16.720 --> 00:33:17.240
you will be using
00:33:19.880 --> 00:33:21.700
like Prometheus for Kubernetes
00:33:21.700 --> 00:33:23.040
and for Linux-based systems
00:33:23.040 --> 00:33:23.560
you will be using
00:33:25.640 --> 00:33:27.980
like Elk Stack all those things
00:33:27.980 --> 00:33:29.680
so but these are like
00:33:29.680 --> 00:33:30.500
different platforms
00:33:30.500 --> 00:33:33.020
and you have for Kubernetes server
00:33:33.020 --> 00:33:34.580
you have to want to go
00:33:34.580 --> 00:33:36.760
with Prometheus dashboards
00:33:36.760 --> 00:33:38.420
and for Linux servers
00:33:38.420 --> 00:33:40.080
you want to go for different dashboards
00:33:40.080 --> 00:33:41.800
and managing all of them
00:33:41.800 --> 00:33:42.800
in different areas
00:33:42.800 --> 00:33:45.420
becomes like lots of tiresome
00:33:45.420 --> 00:33:46.400
to management right
00:33:46.400 --> 00:33:47.400
so that's where
00:33:47.400 --> 00:33:49.040
this built-in dashboard comes into picture
00:33:49.040 --> 00:33:51.680
so it's like we wanted to have
00:33:53.200 --> 00:33:55.000
our own tailored dashboards
00:33:55.000 --> 00:33:56.160
in those scenarios
00:33:56.160 --> 00:33:58.080
we'll be creating these dashboards
00:33:58.080 --> 00:34:00.000
we'll be providing the metrics
00:34:00.000 --> 00:34:01.560
what metrics that we want to provide
00:34:02.320 --> 00:34:03.340
so whenever let's say
00:34:03.340 --> 00:34:05.260
we have deployed a specific application
00:34:05.260 --> 00:34:07.200
like on next class
00:34:07.200 --> 00:34:08.260
like next sessions
00:34:08.260 --> 00:34:09.360
so we'll have this
00:34:10.940 --> 00:34:12.560
everything populated over here
00:34:12.560 --> 00:34:13.360
so that we can have
00:34:14.760 --> 00:34:15.780
hands-on over there
00:34:15.780 --> 00:34:17.520
so this is like
00:34:17.520 --> 00:34:20.060
where we wanted to monitor everything
00:34:20.060 --> 00:34:21.360
in a single dashboard
00:34:21.360 --> 00:34:23.880
in different different deployment aspects
00:34:23.880 --> 00:34:26.000
we'll be using this in that monitoring
00:34:26.640 --> 00:34:27.600
so this is this
00:34:28.960 --> 00:34:30.260
and access management
00:34:30.260 --> 00:34:33.140
like this is one of the most important thing
00:34:33.140 --> 00:34:35.440
in the whole Anypoint implementation
00:34:35.440 --> 00:34:38.420
so here let's say
00:34:38.420 --> 00:34:40.160
your organization wanted to go for
00:34:40.760 --> 00:34:41.960
Anypoint implementation
00:34:41.960 --> 00:34:43.860
and you have let's say
00:34:43.860 --> 00:34:45.120
around 10 applications
00:34:45.120 --> 00:34:46.460
that we wanted to integrate
00:34:46.460 --> 00:34:48.060
with the help of these APIs
00:34:48.720 --> 00:34:50.220
Anypoint address specifically
00:34:50.220 --> 00:34:52.460
and here you have like
00:34:52.460 --> 00:34:54.140
around 15 developers
00:34:54.140 --> 00:34:56.200
and five distinct team
00:34:56.200 --> 00:34:58.240
and two SRE team
00:34:58.240 --> 00:35:00.340
so each and every team
00:35:00.340 --> 00:35:02.580
has its own boundaries
00:35:02.580 --> 00:35:03.900
you can say
00:35:03.900 --> 00:35:04.900
where they wanted to
00:35:04.900 --> 00:35:06.920
like work with Anypoint platform
00:35:06.920 --> 00:35:07.800
for developers
00:35:07.800 --> 00:35:09.740
they mostly wanted to have
00:35:09.740 --> 00:35:13.580
access to specific implementation
00:35:13.580 --> 00:35:16.860
like only running the application
00:35:16.860 --> 00:35:18.060
in their local machine
00:35:18.060 --> 00:35:21.860
and just I mean having
00:35:21.860 --> 00:35:23.760
or debugging implementations over there
00:35:24.140 --> 00:35:25.640
so those aspects
00:35:25.640 --> 00:35:28.240
we wanted to kind of
00:35:28.240 --> 00:35:30.380
restrict their access over there itself
00:35:31.180 --> 00:35:34.580
but let's say for testing users
00:35:34.580 --> 00:35:35.340
we want to have
00:35:36.080 --> 00:35:37.800
different mock APS as well
00:35:37.800 --> 00:35:39.220
because testers mostly use
00:35:39.220 --> 00:35:41.080
on mock servers basically
00:35:41.080 --> 00:35:42.280
so in those scenarios
00:35:42.280 --> 00:35:44.880
we need to provide access to testers
00:35:44.880 --> 00:35:46.460
for there as well
00:35:46.460 --> 00:35:48.700
for deployment or SRE team
00:35:48.700 --> 00:35:50.140
or they need to have access
00:35:50.140 --> 00:35:51.420
over the physical resources
00:35:51.420 --> 00:35:53.200
or servers that we have deployed on
00:35:53.200 --> 00:35:54.060
different clouds
00:35:54.060 --> 00:35:55.200
let's say you wanted to integrate
00:35:55.200 --> 00:35:56.580
Microsoft Azure here
00:35:56.580 --> 00:35:58.420
so you will be having an API key
00:35:58.420 --> 00:36:00.220
that is being created by
00:36:00.220 --> 00:36:00.940
Microsoft Azure
00:36:00.940 --> 00:36:02.360
and you wanted to integrate
00:36:02.360 --> 00:36:04.880
Azure to Anypoint platform
00:36:04.880 --> 00:36:07.000
or Salesforce to Anypoint platform
00:36:07.000 --> 00:36:08.600
or Google APG platform
00:36:08.600 --> 00:36:09.620
to Anypoint platform
00:36:09.620 --> 00:36:11.240
so different different scenarios
00:36:11.240 --> 00:36:12.500
SRE team works on
00:36:12.500 --> 00:36:14.340
so they need to work
00:36:14.340 --> 00:36:15.440
on these specific scenarios
00:36:15.440 --> 00:36:16.740
so we do have
00:36:16.740 --> 00:36:18.420
role-based access controls here
00:36:18.420 --> 00:36:20.780
and we have broad roles
00:36:20.780 --> 00:36:24.420
and a specific organization
00:36:24.420 --> 00:36:26.700
can create their custom roles also
00:36:27.260 --> 00:36:28.860
to provide more granular
00:36:29.400 --> 00:36:31.040
roles and responsibilities
00:36:31.040 --> 00:36:32.180
to a single user
00:36:32.180 --> 00:36:34.700
so that they can just tailor their
00:36:36.200 --> 00:36:37.580
access needs
00:36:37.580 --> 00:36:40.260
so that it's not one size fits
00:36:40.260 --> 00:36:41.280
for everyone right
00:36:41.280 --> 00:36:43.480
so that's where this access management
00:36:43.480 --> 00:36:44.840
dashboard comes into picture
00:36:45.740 --> 00:36:47.220
and as I've told right
00:36:47.220 --> 00:36:48.180
for you let's say you wanted
00:36:48.180 --> 00:36:49.300
to integrate Salesforce
00:36:49.300 --> 00:36:51.120
with Anypoint platform
00:36:51.120 --> 00:36:54.160
so but how this is for
00:36:54.160 --> 00:36:55.400
I mean this Anypoint platform
00:36:55.400 --> 00:36:59.360
it knows that who are you
00:36:59.360 --> 00:37:01.260
you want to work with
00:37:01.260 --> 00:37:03.940
your organization's cloud account
00:37:03.940 --> 00:37:05.140
so you wanted to provide
00:37:05.940 --> 00:37:08.960
SSH key based authentication mechanism
00:37:08.960 --> 00:37:10.680
or API key based
00:37:10.680 --> 00:37:11.760
authentication mechanism
00:37:11.760 --> 00:37:12.860
so you wanted to store
00:37:12.860 --> 00:37:14.560
these keys somewhere else right
00:37:14.560 --> 00:37:15.680
so this secret manager
00:37:15.680 --> 00:37:17.900
provides you that luxury
00:37:17.900 --> 00:37:20.400
store all the SSH keys
00:37:20.400 --> 00:37:22.320
or SSL certificates
00:37:22.320 --> 00:37:24.180
or public keys
00:37:25.020 --> 00:37:27.660
or the API keys and all
00:37:27.660 --> 00:37:31.360
and we have this secret manager
00:37:31.360 --> 00:37:33.440
integrated with the
00:37:33.440 --> 00:37:35.200
Anypoint Studio as well
00:37:35.200 --> 00:37:36.700
so I've told like this
00:37:36.700 --> 00:37:37.220
Anypoint Studio
00:37:37.220 --> 00:37:39.240
it's like local development mechanism
00:37:39.240 --> 00:37:41.480
where developers will be working on
00:37:41.480 --> 00:37:44.300
a specific ID itself
00:37:44.300 --> 00:37:47.640
if you're aware of
00:37:47.640 --> 00:37:48.440
Java development
00:37:48.440 --> 00:37:51.040
we have these Spring Boot IDEs
00:37:51.040 --> 00:37:53.420
and these IDEs right
00:37:53.960 --> 00:37:54.760
what we call them
00:37:56.320 --> 00:37:59.480
file charm or these IDEs
00:37:59.480 --> 00:38:00.300
so they are like
00:38:00.300 --> 00:38:01.460
integrated development environments
00:38:01.460 --> 00:38:03.200
where you can do testing
00:38:03.200 --> 00:38:04.120
you can do debugging
00:38:04.120 --> 00:38:05.180
you can do development
00:38:05.180 --> 00:38:07.900
all it is at a single place
00:38:07.900 --> 00:38:09.660
so you wanted to integrate
00:38:09.660 --> 00:38:10.760
this Anypoint platform
00:38:10.760 --> 00:38:12.280
to those third-party
00:38:13.460 --> 00:38:15.140
applications or third-party APS
00:38:15.140 --> 00:38:15.800
you can just use
00:38:15.800 --> 00:38:16.800
this secret manager
00:38:17.600 --> 00:38:19.220
this secret manager has
00:38:19.220 --> 00:38:20.580
hooks associated with that
00:38:20.580 --> 00:38:22.000
so basically you can just create a hook
00:38:22.000 --> 00:38:23.500
and integrate that hook
00:38:23.500 --> 00:38:25.400
inside your local machines
00:38:25.400 --> 00:38:26.100
environment variable
00:38:26.100 --> 00:38:28.920
and you can just have access to those
00:38:30.000 --> 00:38:31.380
all third-party APS
00:38:31.380 --> 00:38:32.060
as well with the help
00:38:32.060 --> 00:38:32.980
of the secret manager
00:38:32.980 --> 00:38:35.760
so that is the overview
00:38:35.760 --> 00:38:37.660
of this Anypoint platform
00:38:37.660 --> 00:38:39.340
and you also have this
00:38:39.340 --> 00:38:40.680
exchange over here
00:38:40.680 --> 00:38:42.040
so exchange is like
00:38:43.620 --> 00:38:45.200
a public platform
00:38:45.800 --> 00:38:46.940
for a user
00:38:47.560 --> 00:38:49.280
are you aware of Docker?
00:38:49.820 --> 00:38:49.960
by any chance?
00:38:52.260 --> 00:38:52.380
Docker?
00:38:54.800 --> 00:38:56.120
so basically Docker
00:38:56.120 --> 00:38:58.140
is a kind of container
00:38:58.140 --> 00:39:00.520
and shipping platform basically
00:39:00.520 --> 00:39:02.040
let's say you develop the code
00:39:02.040 --> 00:39:03.820
inside your implemented
00:39:03.820 --> 00:39:05.340
I mean inside your local machine
00:39:05.340 --> 00:39:06.380
and you wanted to deploy
00:39:06.380 --> 00:39:07.580
this code somewhere else
00:39:07.580 --> 00:39:09.200
which is very different
00:39:09.200 --> 00:39:10.860
from your development environment
00:39:10.860 --> 00:39:14.020
so you'll be creating artifact
00:39:14.020 --> 00:39:15.600
and shipping those artifacts
00:39:15.600 --> 00:39:17.280
other areas
00:39:17.280 --> 00:39:18.580
where you want to deploy
00:39:18.580 --> 00:39:20.060
whether that may be Kubernetes cluster
00:39:20.060 --> 00:39:21.500
whether that may be a Linux
00:39:21.500 --> 00:39:22.960
a traditional Linux machine
00:39:22.960 --> 00:39:23.960
or any other things
00:39:24.800 --> 00:39:26.580
but you wanted to have
00:39:26.580 --> 00:39:30.800
I mean this jar artifact
00:39:30.800 --> 00:39:31.980
published somewhere
00:39:31.980 --> 00:39:33.380
and all users
00:39:33.380 --> 00:39:34.900
who wants to use this jar artifact
00:39:34.900 --> 00:39:36.780
just go to their marketplace
00:39:36.780 --> 00:39:39.900
and fetch that specific jar artifact
00:39:39.900 --> 00:39:42.040
and use for their own purposes
00:39:42.040 --> 00:39:44.280
so that's how the exchange works
00:39:44.280 --> 00:39:46.080
basically it's a kind of marketplace
00:39:46.080 --> 00:39:48.080
where you publish things
00:39:48.080 --> 00:39:49.720
and other people
00:39:49.720 --> 00:39:50.920
you know utilize those
00:39:51.520 --> 00:39:53.960
already pre-developed APIs
00:39:53.960 --> 00:39:55.320
or connectors or templates
00:39:55.880 --> 00:39:57.860
so that's how the exchange works
00:39:57.860 --> 00:39:59.740
we'll be going through this exchange
00:39:59.740 --> 00:40:02.920
and the design center is also
00:40:03.600 --> 00:40:04.680
we'll be going through
00:40:04.680 --> 00:40:05.660
raml implementations
00:40:05.660 --> 00:40:07.140
so that's where this design center
00:40:07.140 --> 00:40:08.120
comes into picture
00:40:08.840 --> 00:40:11.620
so that's the brief introduction
00:40:11.620 --> 00:40:12.820
about Thumbu software
00:40:15.420 --> 00:40:16.700
kind of
00:40:20.660 --> 00:40:22.820
so now you can stop me anywhere
00:40:22.820 --> 00:40:25.840
if you think things are not necessary
00:40:25.840 --> 00:40:28.260
or you don't want to have
00:40:38.080 --> 00:40:39.880
so these are these things
00:40:39.880 --> 00:40:40.680
that I've already covered
00:40:40.680 --> 00:40:42.200
basically this API manager
00:40:42.200 --> 00:40:45.460
you can just write our raml codes
00:40:45.460 --> 00:40:46.000
right away
00:40:46.000 --> 00:40:48.360
and we can just create our urls
00:40:48.360 --> 00:40:49.760
and test those urls as well
00:40:49.760 --> 00:40:50.800
with the help of API manager
00:40:50.800 --> 00:40:51.400
we'll be doing that
00:40:52.580 --> 00:40:54.120
in subsequent in subsequent hours
00:40:54.800 --> 00:40:55.900
and runtime manager
00:40:55.900 --> 00:40:57.080
it's like specifically
00:40:58.220 --> 00:40:59.820
let's say for cloud implementations
00:40:59.820 --> 00:41:00.420
which therefore
00:41:00.420 --> 00:41:01.800
azure cloud implementations
00:41:02.420 --> 00:41:04.300
we have a specific java-based
00:41:04.300 --> 00:41:05.000
runtime managers
00:41:05.720 --> 00:41:06.840
and for python-based
00:41:07.760 --> 00:41:08.780
API integrations
00:41:08.780 --> 00:41:10.700
we have python runtime managers
00:41:10.700 --> 00:41:12.420
so we wanted to run
00:41:12.420 --> 00:41:13.700
or we wanted to integrate
00:41:13.700 --> 00:41:16.460
a different runtime
00:41:17.680 --> 00:41:18.300
implementations
00:41:18.300 --> 00:41:19.660
let's say javascript
00:41:19.660 --> 00:41:21.760
or java or python-based codes
00:41:21.760 --> 00:41:23.380
basically we will be doing
00:41:23.380 --> 00:41:25.180
using that with the help of weaves
00:41:26.200 --> 00:41:27.340
weave is a kind of
00:41:27.340 --> 00:41:28.400
data transmission language
00:41:28.400 --> 00:41:30.560
that we will be using in newsoft
00:41:30.560 --> 00:41:31.900
we'll be discussing that later
00:41:31.900 --> 00:41:34.380
but yeah those weave
00:41:34.380 --> 00:41:35.940
implementations requires
00:41:35.940 --> 00:41:37.000
our runtime managers
00:41:37.000 --> 00:41:38.200
so that we can define
00:41:38.200 --> 00:41:39.640
what exactly the language
00:41:39.640 --> 00:41:40.180
that we're using
00:41:40.180 --> 00:41:41.720
and we can integrate that
00:41:41.720 --> 00:41:44.480
so it's like multimodal
00:41:44.480 --> 00:41:46.460
integrations inside the newsoft
00:41:48.320 --> 00:41:49.840
and mq
00:41:49.840 --> 00:41:52.720
so basically this mq is like
00:41:52.720 --> 00:41:54.460
if you know apache kafka
00:41:54.460 --> 00:41:56.580
or cloud native implementations
00:41:56.580 --> 00:41:58.380
like azure service bus
00:41:58.380 --> 00:42:00.680
or aws sns
00:42:00.680 --> 00:42:02.780
or those service bus mechanisms
00:42:02.780 --> 00:42:05.440
so basically these mqs
00:42:05.440 --> 00:42:06.660
or precision queues
00:42:06.660 --> 00:42:07.820
are basically like
00:42:08.660 --> 00:42:10.560
you will be publishing a message
00:42:12.200 --> 00:42:13.940
and our api which is
00:42:13.940 --> 00:42:15.420
subscribed to this message
00:42:15.420 --> 00:42:16.640
will be continuously
00:42:16.640 --> 00:42:18.080
pulling over the queue
00:42:18.080 --> 00:42:20.120
that you have subscribed
00:42:20.120 --> 00:42:22.380
and continuously listening over there
00:42:22.380 --> 00:42:23.880
so that we can integrate
00:42:26.360 --> 00:42:27.780
publisher and subscriber
00:42:27.780 --> 00:42:28.660
subscriber mechanism
00:42:28.660 --> 00:42:32.440
with the actual deliveries
00:42:32.440 --> 00:42:33.860
that we are going to work on
00:42:33.860 --> 00:42:34.740
so basically it's like
00:42:34.740 --> 00:42:36.420
kind of architectural decision
00:42:36.420 --> 00:42:37.620
that we have made
00:42:38.180 --> 00:42:39.860
for this publisher
00:42:39.860 --> 00:42:40.940
and subscriber mechanism
00:42:40.940 --> 00:42:43.080
and newsoft integration tool
00:42:43.080 --> 00:42:44.300
like this is a kind of
00:42:44.300 --> 00:42:45.700
newsoft integration tool itself
00:42:45.700 --> 00:42:47.400
we call that as messaging queue
00:42:48.100 --> 00:42:49.900
and it is tightly coupled
00:42:49.900 --> 00:42:50.720
with the newsoft
00:42:50.720 --> 00:42:53.100
so that it has its
00:42:53.100 --> 00:42:55.180
i mean this mq has its
00:42:55.180 --> 00:42:56.200
cloud native implementation
00:42:56.200 --> 00:42:57.320
of newsoft
00:42:57.320 --> 00:42:58.680
when i say cloud native
00:42:58.680 --> 00:42:59.980
you don't need to go
00:42:59.980 --> 00:43:01.700
to any other specific cloud
00:43:01.700 --> 00:43:03.560
or manage it somewhere else
00:43:03.560 --> 00:43:05.520
you have i mean you can just manage it
00:43:05.520 --> 00:43:07.180
under the same roof of any point
00:43:07.620 --> 00:43:09.780
so that is the thing and
00:43:11.520 --> 00:43:13.000
so yeah that's all about
00:43:13.000 --> 00:43:14.860
any point as we go through
00:43:14.860 --> 00:43:16.320
the practical things
00:43:16.320 --> 00:43:18.080
so you can just correlate
00:43:18.080 --> 00:43:19.380
things what i've told right now
00:43:20.060 --> 00:43:21.060
much more easily
00:43:21.780 --> 00:43:23.840
and like till till now
00:43:23.840 --> 00:43:25.920
i've told api api api
00:43:25.920 --> 00:43:27.000
a lot many times right
00:43:27.000 --> 00:43:29.360
so what is this specific api
00:43:29.360 --> 00:43:31.540
like how exactly this api
00:43:32.580 --> 00:43:33.380
comes into picture
00:43:33.380 --> 00:43:35.980
with respect to newsoft language
00:43:35.980 --> 00:43:39.020
so basically this new api
00:43:39.700 --> 00:43:41.180
do you have any like
00:43:42.960 --> 00:43:44.700
previous experience
00:43:44.700 --> 00:43:45.740
with the development or
00:43:46.480 --> 00:43:47.560
those scenarios
00:43:48.220 --> 00:43:49.780
or software development areas
00:43:50.620 --> 00:43:52.360
okay good okay
00:43:52.360 --> 00:43:55.420
so basically api is
00:43:55.420 --> 00:43:56.800
a kind of
00:43:56.800 --> 00:43:58.120
application programming interface
00:43:58.120 --> 00:44:01.360
we call and that is the
00:44:01.360 --> 00:44:02.720
short form of api
00:44:02.720 --> 00:44:05.140
so this api is specifically
00:44:06.020 --> 00:44:08.080
let's say you have three applications
00:44:08.080 --> 00:44:10.280
and these three applications
00:44:10.280 --> 00:44:11.080
need to communicate
00:44:11.080 --> 00:44:11.900
between themselves
00:44:12.580 --> 00:44:13.700
right now we are using
00:44:13.700 --> 00:44:16.300
english as our language of communication
00:44:17.820 --> 00:44:19.420
but our programs
00:44:19.420 --> 00:44:21.540
doesn't know about english right
00:44:21.540 --> 00:44:23.420
so they wanted to have
00:44:23.420 --> 00:44:24.800
a specific language
00:44:25.540 --> 00:44:26.340
where they wanted to
00:44:27.240 --> 00:44:28.440
communicate within each
00:44:28.440 --> 00:44:29.040
each and everything
00:44:29.780 --> 00:44:31.120
i mean with each other
00:44:31.120 --> 00:44:33.380
so that's what an api is
00:44:33.380 --> 00:44:36.740
so api has its own rules and
00:44:36.740 --> 00:44:39.060
like a hard-coded rules
00:44:39.060 --> 00:44:40.880
where if you wanted to
00:44:40.880 --> 00:44:42.240
get some information from
00:44:42.240 --> 00:44:44.280
a specific or deploying
00:44:44.280 --> 00:44:45.140
deployed application
00:44:45.140 --> 00:44:47.180
you want to query that first
00:44:47.180 --> 00:44:49.460
i want this information from you
00:44:49.460 --> 00:44:50.540
you want i mean you
00:44:50.540 --> 00:44:51.740
should give me this information
00:44:52.500 --> 00:44:53.980
that is the way you pass
00:44:53.980 --> 00:44:56.480
and it responds to you
00:44:56.480 --> 00:44:57.560
in a specific way
00:44:57.560 --> 00:44:58.880
as a json response
00:44:58.880 --> 00:45:00.940
json is javascript object notation
00:45:00.940 --> 00:45:01.980
so basically
00:45:06.120 --> 00:45:08.160
you have this request
00:45:10.760 --> 00:45:13.820
you have this response provided by api
00:45:15.700 --> 00:45:17.020
so this is the api which
00:45:18.040 --> 00:45:20.260
works between the request and response
00:45:22.180 --> 00:45:24.260
so how you provide request
00:45:25.080 --> 00:45:27.000
is one thing one question
00:45:27.000 --> 00:45:28.820
you have to have solution for that
00:45:28.820 --> 00:45:31.540
and how it provides the response
00:45:31.540 --> 00:45:33.060
we need to have information
00:45:33.060 --> 00:45:34.040
regarding that as well
00:45:34.040 --> 00:45:36.100
let's say it responded to you
00:45:36.100 --> 00:45:37.300
in arabic you can't
00:45:37.300 --> 00:45:38.340
able to understand right
00:45:38.340 --> 00:45:40.520
so there should be pre-understand
00:45:40.520 --> 00:45:42.980
convention between a caller
00:45:42.980 --> 00:45:44.420
and a provider
00:45:44.420 --> 00:45:46.000
so basically that
00:45:46.000 --> 00:45:47.620
pre-understanding convention
00:45:47.620 --> 00:45:49.220
is called an api
00:45:49.220 --> 00:45:50.820
basically you have a specific
00:45:50.820 --> 00:45:51.740
api specifications
00:45:51.740 --> 00:45:53.840
like i'll be providing you
00:45:53.840 --> 00:45:55.320
a request in specific form
00:45:55.320 --> 00:45:56.480
and you have to listen
00:45:56.480 --> 00:45:57.240
to this request
00:45:57.240 --> 00:45:58.380
and you have to provide
00:45:58.820 --> 00:46:00.900
response to me in this specific form
00:46:00.900 --> 00:46:02.980
so that is the way an api
00:46:05.140 --> 00:46:06.120
works basically
00:46:06.740 --> 00:46:09.360
so it consists of
00:46:09.360 --> 00:46:10.200
all these request
00:46:10.200 --> 00:46:11.860
and response based scenarios
00:46:12.680 --> 00:46:14.860
but how this i mean
00:46:14.860 --> 00:46:16.660
api sits with mulesoft basically
00:46:17.220 --> 00:46:19.400
as we have already discussed
00:46:19.400 --> 00:46:21.140
mulesoft is kind of
00:46:21.140 --> 00:46:22.060
integration platform
00:46:22.060 --> 00:46:23.020
first and foremost thing
00:46:23.020 --> 00:46:26.160
it provides us a way to integrate
00:46:26.160 --> 00:46:27.500
different different applications
00:46:27.500 --> 00:46:29.280
which are deployed across
00:46:29.280 --> 00:46:30.440
different environment
00:46:30.440 --> 00:46:33.100
and sometimes we don't even know
00:46:33.100 --> 00:46:35.760
where i mean it is kind of
00:46:35.760 --> 00:46:36.540
abstracted from us
00:46:37.260 --> 00:46:38.580
where a specific application
00:46:38.580 --> 00:46:39.160
is deployed
00:46:39.160 --> 00:46:40.620
but as long as you are
00:46:40.620 --> 00:46:41.480
hitting that application
00:46:41.480 --> 00:46:42.740
it is providing the response
00:46:43.260 --> 00:46:43.980
with the help of
00:46:45.340 --> 00:46:46.380
api keys and all
00:46:46.380 --> 00:46:47.640
so that's where let's say
00:46:47.640 --> 00:46:48.700
three developers worked on
00:46:49.420 --> 00:46:51.200
one of the implementations
00:46:51.200 --> 00:46:52.360
so let's say you have
00:46:52.360 --> 00:46:53.380
a vendor with you
00:46:53.380 --> 00:46:55.000
and that vendor takes
00:46:55.000 --> 00:46:56.240
the responsibility of delivering
00:46:56.240 --> 00:46:57.780
the api
00:46:57.780 --> 00:47:00.020
and you wanted to build
00:47:00.020 --> 00:47:02.660
a application on top of this api
00:47:02.660 --> 00:47:03.700
and you wanted to deliver
00:47:03.700 --> 00:47:05.300
this as a kind of product
00:47:05.300 --> 00:47:06.400
to your clients
00:47:06.400 --> 00:47:08.360
so you have a dependency
00:47:08.360 --> 00:47:09.400
with one of the team
00:47:09.400 --> 00:47:10.780
and that team
00:47:10.780 --> 00:47:12.120
continuously deploys
00:47:12.120 --> 00:47:13.480
and delivers everything
00:47:13.480 --> 00:47:15.720
like right now
00:47:15.720 --> 00:47:16.880
this week you have
00:47:16.880 --> 00:47:18.060
api version v1
00:47:18.060 --> 00:47:20.760
and going forward on next week
00:47:20.760 --> 00:47:21.640
they deployed
00:47:21.640 --> 00:47:23.100
api version v2
00:47:23.100 --> 00:47:25.020
but right now your application
00:47:25.020 --> 00:47:27.180
mostly works for api v1
00:47:27.180 --> 00:47:28.020
and you don't know
00:47:28.020 --> 00:47:29.760
what exactly the conventions
00:47:29.760 --> 00:47:31.660
that are changed for api
00:47:32.660 --> 00:47:34.940
for v4 sorry 1.4
00:47:34.940 --> 00:47:35.900
so let's say
00:47:35.900 --> 00:47:37.780
as you i mean
00:47:37.780 --> 00:47:39.440
if you know how
00:47:39.440 --> 00:47:40.460
api convention works
00:47:40.460 --> 00:47:42.800
basically let's say
00:47:42.800 --> 00:47:44.000
the version changes happens
00:47:44.000 --> 00:47:46.120
and the predefined
00:47:46.120 --> 00:47:47.160
convention also changes
00:47:47.160 --> 00:47:48.160
with those specific
00:47:48.160 --> 00:47:48.840
version changes
00:47:48.840 --> 00:47:50.460
and you have to understand
00:47:50.460 --> 00:47:51.740
what exactly changed
00:47:51.740 --> 00:47:52.780
are there any breaking
00:47:52.780 --> 00:47:53.900
changes over there
00:47:53.900 --> 00:47:55.060
and and all
00:47:55.060 --> 00:47:57.260
so like when it comes
00:47:57.260 --> 00:47:58.060
to version changes
00:47:58.060 --> 00:47:58.960
managing them
00:47:58.960 --> 00:47:59.460
and maintaining
00:47:59.460 --> 00:48:00.240
the version changes
00:48:00.240 --> 00:48:01.660
becomes a lot of help for us
00:48:02.220 --> 00:48:04.060
when we manage them
00:48:04.760 --> 00:48:06.300
like standalone implementations
00:48:06.300 --> 00:48:07.660
so that's where
00:48:07.660 --> 00:48:09.480
this mule point sits on
00:48:09.480 --> 00:48:11.580
so for all these
00:48:13.220 --> 00:48:14.620
api conventions like
00:48:15.320 --> 00:48:17.560
this is like being abstracted
00:48:17.560 --> 00:48:20.320
by mule soft itself
00:48:20.320 --> 00:48:22.660
so the basically this area
00:48:22.660 --> 00:48:24.320
is where you integrate
00:48:24.320 --> 00:48:24.940
the mule soft
00:48:24.940 --> 00:48:26.780
so that you can have
00:48:26.780 --> 00:48:28.360
integration with the
00:48:28.360 --> 00:48:29.500
dependency teams
00:48:29.500 --> 00:48:30.680
and the product
00:48:30.680 --> 00:48:31.260
that you're delivering
00:48:31.260 --> 00:48:32.040
to your customers
00:48:32.040 --> 00:48:33.760
so that you have your
00:48:34.420 --> 00:48:35.380
fine-grained control
00:48:35.380 --> 00:48:36.580
over which api version
00:48:36.580 --> 00:48:38.360
you use and all
00:48:38.360 --> 00:48:39.480
so that's where
00:48:40.100 --> 00:48:41.180
like the upstream
00:48:41.180 --> 00:48:42.740
and utilizers
00:48:42.740 --> 00:48:43.760
where end product
00:48:43.760 --> 00:48:44.720
is delivered
00:48:44.720 --> 00:48:45.440
are connected
00:48:45.440 --> 00:48:46.720
with the help of mule soft
00:48:46.720 --> 00:48:48.100
i guess that makes sense
00:48:51.210 --> 00:48:53.070
yeah so till now
00:48:53.930 --> 00:48:55.250
we discussed about
00:48:55.250 --> 00:48:55.930
what is api
00:48:55.930 --> 00:48:56.950
what is api and all
00:48:56.950 --> 00:48:59.210
but this is a kind of
00:48:59.210 --> 00:48:59.950
broad definition
00:48:59.950 --> 00:49:02.550
we haven't gone till into
00:49:02.550 --> 00:49:03.370
our specifications
00:49:03.370 --> 00:49:05.590
how this api is designed
00:49:05.590 --> 00:49:06.810
how this api
00:49:06.810 --> 00:49:08.350
actually created and all
00:49:08.350 --> 00:49:10.030
right so that's where
00:49:10.030 --> 00:49:11.390
raml language comes into picture
00:49:11.390 --> 00:49:13.170
so as i have told right
00:49:13.170 --> 00:49:14.170
a pre-understand
00:49:14.170 --> 00:49:15.730
or pre-defined convention
00:49:15.730 --> 00:49:17.230
so what is the specific
00:49:17.230 --> 00:49:18.230
pre-defined convention
00:49:18.350 --> 00:49:19.950
so that is raml
00:49:20.670 --> 00:49:22.330
so basically raml
00:49:22.330 --> 00:49:22.910
is a kind of
00:49:23.950 --> 00:49:24.970
universal language
00:49:24.970 --> 00:49:25.390
you can say
00:49:26.110 --> 00:49:27.870
in terms of mule soft
00:49:27.870 --> 00:49:29.330
and we have
00:49:29.330 --> 00:49:30.470
other applications as well
00:49:30.470 --> 00:49:31.730
which are created
00:49:31.730 --> 00:49:32.910
on top of raml language
00:49:32.910 --> 00:49:34.630
that is out of topic right now
00:49:34.630 --> 00:49:36.510
so but yeah raml is
00:49:36.510 --> 00:49:37.350
a language
00:49:37.350 --> 00:49:39.250
people use to create
00:49:39.250 --> 00:49:40.250
their api's
00:49:40.250 --> 00:49:41.550
and just publish their api's
00:49:42.430 --> 00:49:44.150
inside this delivery exchange
00:49:44.150 --> 00:49:46.690
so that people can just
00:49:46.690 --> 00:49:48.330
grab those raml
00:49:48.330 --> 00:49:49.010
specifications
00:49:49.010 --> 00:49:50.510
and build their applications
00:49:50.510 --> 00:49:51.730
or build their integrations
00:49:51.730 --> 00:49:52.470
on top of that
00:49:52.470 --> 00:49:54.410
so that's where raml
00:49:54.410 --> 00:49:55.270
comes into picture
00:49:55.270 --> 00:49:56.510
so whenever
00:49:58.130 --> 00:50:00.350
i mean till now
00:50:00.350 --> 00:50:01.250
i'm telling implementation
00:50:01.250 --> 00:50:02.350
implementation and implementation
00:50:02.350 --> 00:50:03.430
so what is this
00:50:03.430 --> 00:50:04.150
specific implementation
00:50:04.150 --> 00:50:05.690
so we wanted to define
00:50:06.510 --> 00:50:07.530
a way
00:50:08.370 --> 00:50:09.590
endpoint response
00:50:09.590 --> 00:50:11.270
so let's say i have created
00:50:11.270 --> 00:50:12.330
a endpoint called
00:50:12.850 --> 00:50:14.190
products endpoint
00:50:15.330 --> 00:50:16.450
products endpoint
00:50:17.410 --> 00:50:19.330
and basically this
00:50:19.330 --> 00:50:19.790
product endpoint
00:50:19.790 --> 00:50:21.170
is mostly responsible for
00:50:22.290 --> 00:50:23.570
providing you
00:50:23.570 --> 00:50:24.530
a list of products
00:50:25.630 --> 00:50:27.070
like like you have
00:50:27.070 --> 00:50:28.090
a catalog with you
00:50:28.090 --> 00:50:30.250
and you have this catalog
00:50:30.250 --> 00:50:30.930
says that
00:50:30.930 --> 00:50:32.530
you have product one
00:50:37.070 --> 00:50:38.270
et and all
00:50:38.270 --> 00:50:39.890
so you wanted to tell your
00:50:41.670 --> 00:50:43.030
application programmers
00:50:43.030 --> 00:50:44.130
that i have this
00:50:45.610 --> 00:50:46.770
products with me
00:50:46.770 --> 00:50:47.670
but how can you tell
00:50:47.670 --> 00:50:48.930
so you'll be implementing
00:50:48.930 --> 00:50:49.810
a product api
00:50:50.730 --> 00:50:52.270
and this product api
00:50:52.270 --> 00:50:53.870
is like responsible to throw
00:50:53.870 --> 00:50:55.330
what is what is the catalog
00:50:55.330 --> 00:50:55.950
that you have
00:50:55.950 --> 00:50:57.570
so whenever let's say
00:50:57.570 --> 00:50:58.610
a developer hits
00:50:58.610 --> 00:50:59.690
this product api
00:51:00.310 --> 00:51:01.690
he'll get the list of products
00:51:02.250 --> 00:51:03.290
no matter
00:51:05.050 --> 00:51:06.250
your implementation
00:51:06.250 --> 00:51:07.370
has changed a lot
00:51:07.370 --> 00:51:08.070
let's say
00:51:08.070 --> 00:51:09.750
you have migrated from
00:51:09.750 --> 00:51:10.250
java-based
00:51:11.530 --> 00:51:12.730
implementation to
00:51:12.730 --> 00:51:13.690
python-based servers
00:51:13.690 --> 00:51:15.110
lot of your architecture
00:51:15.110 --> 00:51:15.910
has changed
00:51:16.730 --> 00:51:17.570
you don't care about
00:51:17.570 --> 00:51:18.290
any of those
00:51:18.290 --> 00:51:19.130
you just tell
00:51:19.690 --> 00:51:20.950
your integration team
00:51:20.950 --> 00:51:21.850
that let's say
00:51:21.850 --> 00:51:22.490
you wanted to have
00:51:22.490 --> 00:51:23.050
list of products
00:51:23.050 --> 00:51:24.130
just hit this
00:51:24.130 --> 00:51:25.290
you don't need to care about
00:51:26.230 --> 00:51:27.470
what exactly
00:51:27.470 --> 00:51:28.890
how exactly it is implemented
00:51:28.890 --> 00:51:30.330
so that's where
00:51:30.870 --> 00:51:32.610
an api raml
00:51:32.610 --> 00:51:33.470
language implementation
00:51:33.470 --> 00:51:34.150
comes into picture
00:51:34.150 --> 00:51:35.250
so it's basically
00:51:36.090 --> 00:51:36.950
you hit this
00:51:36.950 --> 00:51:38.010
i'll give you this
00:51:38.010 --> 00:51:39.710
so that's where it works
00:51:39.710 --> 00:51:41.410
so we'll be defining
00:51:42.250 --> 00:51:43.670
what exactly
00:51:43.690 --> 00:51:45.050
things are going to be
00:51:45.050 --> 00:51:46.150
like how you handle
00:51:46.150 --> 00:51:47.210
the incoming request
00:51:47.210 --> 00:51:48.230
inside your api
00:51:48.230 --> 00:51:49.170
so that you can
00:51:49.170 --> 00:51:50.430
process the api
00:51:50.430 --> 00:51:51.030
and interact
00:51:51.030 --> 00:51:52.390
with this api
00:51:52.390 --> 00:51:53.290
to our backend systems
00:51:53.290 --> 00:51:54.170
so let's say
00:51:54.170 --> 00:51:54.490
you have
00:51:55.650 --> 00:51:56.850
backend database
00:51:56.850 --> 00:51:57.690
connected to your
00:51:57.690 --> 00:51:58.830
implementing application
00:51:59.870 --> 00:52:01.850
and you wanted to level
00:52:01.850 --> 00:52:03.190
so let's say
00:52:03.190 --> 00:52:03.670
right now
00:52:03.670 --> 00:52:04.750
this is a get request
00:52:05.450 --> 00:52:07.610
so if you have an idea
00:52:07.610 --> 00:52:08.970
on how
00:52:08.970 --> 00:52:10.150
HTTP request works
00:52:10.150 --> 00:52:11.770
in software-based
00:52:11.770 --> 00:52:12.510
implementations
00:52:12.510 --> 00:52:13.670
we call that as
00:52:14.490 --> 00:52:15.250
implementations
00:52:15.250 --> 00:52:17.550
so this restful implementations
00:52:17.550 --> 00:52:18.650
provides you a picture
00:52:19.430 --> 00:52:22.790
that let's say
00:52:22.790 --> 00:52:23.430
no matter what
00:52:24.930 --> 00:52:26.270
you've done
00:52:27.190 --> 00:52:29.110
the systems state
00:52:29.110 --> 00:52:31.370
before your request
00:52:31.370 --> 00:52:32.630
and after your request
00:52:32.630 --> 00:52:33.790
should be same
00:52:34.310 --> 00:52:35.490
so let's say
00:52:35.490 --> 00:52:36.070
i wanted to
00:52:37.070 --> 00:52:37.930
post a product
00:52:37.930 --> 00:52:39.070
to your catalog
00:52:39.070 --> 00:52:40.390
or you can't just
00:52:40.390 --> 00:52:41.210
go to database
00:52:41.210 --> 00:52:41.910
by yourself
00:52:41.910 --> 00:52:43.490
and push the product
00:52:43.490 --> 00:52:45.390
so you wanted to have
00:52:45.390 --> 00:52:46.550
an api with you
00:52:46.550 --> 00:52:47.450
we call that as a
00:52:47.450 --> 00:52:48.610
post api
00:52:48.610 --> 00:52:49.330
or put api
00:52:50.050 --> 00:52:50.810
so basically
00:52:50.810 --> 00:52:51.550
post api
00:52:51.550 --> 00:52:51.970
or put api
00:52:53.310 --> 00:52:54.630
you can stop me
00:52:54.630 --> 00:52:55.390
if you don't
00:52:55.390 --> 00:52:56.150
wanted to listen
00:52:56.150 --> 00:52:56.830
this because
00:52:56.830 --> 00:52:57.750
this is
00:52:57.750 --> 00:52:58.590
like away from
00:53:00.390 --> 00:53:01.830
so yeah exactly
00:53:01.830 --> 00:53:02.650
if you wanted to
00:53:02.650 --> 00:53:03.130
understand
00:53:03.130 --> 00:53:04.050
use of implementations
00:53:04.050 --> 00:53:04.590
we have to
00:53:04.590 --> 00:53:05.470
understand this terminology
00:53:05.470 --> 00:53:06.070
basically
00:53:06.070 --> 00:53:07.050
this is the kind of
00:53:07.690 --> 00:53:08.210
prerequisite
00:53:09.430 --> 00:53:10.870
so post and put
00:53:10.870 --> 00:53:12.030
it's a kind of
00:53:12.030 --> 00:53:12.770
request that you
00:53:12.770 --> 00:53:14.610
to the application
00:53:14.610 --> 00:53:16.150
in term of api level
00:53:16.150 --> 00:53:17.290
not a database level
00:53:17.290 --> 00:53:19.010
so for the
00:53:19.010 --> 00:53:19.430
three layer
00:53:19.430 --> 00:53:20.550
implementations
00:53:20.550 --> 00:53:21.890
first we'll be having
00:53:22.510 --> 00:53:23.570
user level
00:53:24.970 --> 00:53:26.370
where user
00:53:26.370 --> 00:53:27.030
end user
00:53:27.030 --> 00:53:27.690
directly interacts
00:53:27.690 --> 00:53:28.470
with the application
00:53:28.470 --> 00:53:29.410
and we have
00:53:29.410 --> 00:53:30.530
business logic
00:53:32.270 --> 00:53:33.810
and database layer
00:53:36.670 --> 00:53:38.570
and in this
00:53:38.570 --> 00:53:39.250
whole ecosystem
00:53:39.810 --> 00:53:41.150
new soft comes
00:53:41.150 --> 00:53:42.650
and business layer
00:53:42.650 --> 00:53:43.770
business logic layer
00:53:43.770 --> 00:53:45.450
so but
00:53:45.450 --> 00:53:46.150
let's say
00:53:46.150 --> 00:53:46.770
you wanted to
00:53:46.770 --> 00:53:47.470
create a catalog
00:53:47.470 --> 00:53:48.370
or add an item
00:53:48.370 --> 00:53:49.050
to the catalog
00:53:49.050 --> 00:53:50.150
you'll be having
00:53:50.150 --> 00:53:51.190
post request with you
00:53:51.190 --> 00:53:51.930
so the user
00:53:51.930 --> 00:53:53.010
pushes a post request
00:53:53.010 --> 00:53:53.790
it goes to the
00:53:53.790 --> 00:53:54.490
business logic layer
00:53:54.490 --> 00:53:55.550
and you will be
00:53:55.550 --> 00:53:56.010
defining
00:53:56.010 --> 00:53:57.150
what exactly
00:53:57.150 --> 00:53:57.870
you need to do
00:53:57.870 --> 00:53:58.490
in terms of
00:54:00.410 --> 00:54:00.970
like
00:54:00.970 --> 00:54:02.470
how the
00:54:02.470 --> 00:54:02.890
put request
00:54:02.890 --> 00:54:03.690
to respond
00:54:04.470 --> 00:54:05.590
it requires
00:54:05.590 --> 00:54:06.370
like
00:54:06.370 --> 00:54:07.510
internal implementations
00:54:07.510 --> 00:54:08.250
about like
00:54:08.250 --> 00:54:08.770
what database
00:54:08.770 --> 00:54:09.610
that you use
00:54:09.610 --> 00:54:10.370
I use
00:54:10.370 --> 00:54:10.950
post with
00:54:10.950 --> 00:54:11.710
SQL instances
00:54:11.710 --> 00:54:12.630
or use
00:54:12.630 --> 00:54:13.490
MongoDB
00:54:13.490 --> 00:54:14.170
or use
00:54:14.170 --> 00:54:14.630
CosmoDB
00:54:14.630 --> 00:54:15.070
database
00:54:15.070 --> 00:54:15.950
that
00:54:15.950 --> 00:54:16.870
user doesn't need
00:54:16.870 --> 00:54:17.530
to care about
00:54:17.530 --> 00:54:18.150
so basically
00:54:18.150 --> 00:54:19.010
he just wanted to
00:54:19.010 --> 00:54:19.450
push that
00:54:19.450 --> 00:54:20.390
and it should be
00:54:21.130 --> 00:54:21.930
reflecting into
00:54:21.930 --> 00:54:22.250
database
00:54:22.250 --> 00:54:23.730
so that's how
00:54:23.730 --> 00:54:24.410
put and post
00:54:24.410 --> 00:54:24.730
work
00:54:24.730 --> 00:54:25.770
and we also have
00:54:25.770 --> 00:54:26.310
this
00:54:26.310 --> 00:54:26.870
get as well
00:54:28.770 --> 00:54:29.870
and we have
00:54:29.870 --> 00:54:30.470
this patch
00:54:32.270 --> 00:54:33.330
we'll be discussing
00:54:33.330 --> 00:54:34.610
the implementations
00:54:34.610 --> 00:54:35.090
later
00:54:35.090 --> 00:54:35.930
the help of
00:54:35.930 --> 00:54:36.650
core examples
00:54:36.650 --> 00:54:37.790
and we have
00:54:37.790 --> 00:54:39.010
this get APH
00:54:39.010 --> 00:54:40.050
and all
00:54:40.050 --> 00:54:40.630
sorry
00:54:40.630 --> 00:54:41.530
delete APH
00:54:42.630 --> 00:54:43.910
and then
00:54:43.910 --> 00:54:44.830
post output
00:54:44.830 --> 00:54:45.990
so these are
00:54:45.990 --> 00:54:46.990
preliminary APIs
00:54:47.910 --> 00:54:48.710
what one
00:54:49.910 --> 00:54:50.850
user can
00:54:50.850 --> 00:54:51.370
you know
00:54:51.370 --> 00:54:51.830
integrate
00:54:51.830 --> 00:54:52.990
or respond
00:54:53.750 --> 00:54:54.890
to a business logic
00:54:54.890 --> 00:54:55.690
implementations
00:54:55.690 --> 00:54:57.710
so that's how
00:54:57.710 --> 00:54:58.790
we'll be designing
00:54:59.430 --> 00:55:01.010
raml implementations
00:55:02.110 --> 00:55:03.110
so
00:55:03.750 --> 00:55:04.790
that's the thing
00:55:04.790 --> 00:55:05.390
and
00:55:07.350 --> 00:55:08.310
that is one of the
00:55:08.310 --> 00:55:09.250
use case of
00:55:09.250 --> 00:55:09.730
raml
00:55:09.730 --> 00:55:10.450
implementations
00:55:10.450 --> 00:55:11.130
and
00:55:11.130 --> 00:55:11.970
when it comes to
00:55:11.970 --> 00:55:12.890
raml management
00:55:13.670 --> 00:55:14.270
like
00:55:14.890 --> 00:55:16.050
it's not about
00:55:16.050 --> 00:55:16.670
just
00:55:16.670 --> 00:55:17.450
like providing
00:55:20.630 --> 00:55:21.230
implementation
00:55:21.230 --> 00:55:21.750
one time
00:55:21.750 --> 00:55:22.330
and
00:55:22.330 --> 00:55:23.050
your job is done
00:55:23.050 --> 00:55:24.070
it's not like that
00:55:24.070 --> 00:55:24.730
so we have to
00:55:25.810 --> 00:55:26.410
maintain
00:55:26.410 --> 00:55:27.070
that specific
00:55:27.070 --> 00:55:27.550
implementation
00:55:27.550 --> 00:55:28.190
as well
00:55:28.190 --> 00:55:28.730
so let's say
00:55:28.730 --> 00:55:28.970
you have
00:55:28.970 --> 00:55:29.210
created
00:55:29.210 --> 00:55:30.010
implementation
00:55:30.010 --> 00:55:30.850
you need to
00:55:30.850 --> 00:55:31.470
provide a
00:55:31.470 --> 00:55:32.510
documentation for that
00:55:32.510 --> 00:55:33.150
so
00:55:33.150 --> 00:55:34.010
mostly
00:55:34.010 --> 00:55:34.790
use of
00:55:34.790 --> 00:55:35.610
developers are
00:55:35.610 --> 00:55:36.610
the middlemen
00:55:36.610 --> 00:55:37.650
so they have
00:55:37.650 --> 00:55:38.370
stream developers
00:55:38.370 --> 00:55:38.790
as well
00:55:38.790 --> 00:55:39.510
they have downstream
00:55:39.510 --> 00:55:40.550
application
00:55:40.550 --> 00:55:41.810
users as well
00:55:41.810 --> 00:55:42.550
who will be
00:55:42.550 --> 00:55:43.070
consuming these
00:55:43.070 --> 00:55:43.370
APIs
00:55:43.370 --> 00:55:44.910
so you need to have
00:55:44.910 --> 00:55:46.490
documentation with you
00:55:46.490 --> 00:55:47.750
which is
00:55:47.750 --> 00:55:48.130
like
00:55:48.130 --> 00:55:50.010
kind of
00:55:50.010 --> 00:55:50.850
well described
00:55:50.850 --> 00:55:51.450
documentation
00:55:52.130 --> 00:55:52.770
so
00:55:52.770 --> 00:55:54.410
as a
00:55:54.410 --> 00:55:55.110
raml developers
00:55:55.110 --> 00:55:56.310
we are responsible
00:55:56.310 --> 00:55:57.030
for delivering this
00:55:58.210 --> 00:55:59.350
management of
00:55:59.350 --> 00:55:59.990
I mean
00:55:59.990 --> 00:56:00.710
the documentation
00:56:00.710 --> 00:56:01.150
management
00:56:01.150 --> 00:56:02.290
for this as well
00:56:02.290 --> 00:56:02.750
and
00:56:02.750 --> 00:56:03.470
we have to
00:56:03.470 --> 00:56:03.910
manage the
00:56:03.910 --> 00:56:04.490
life cycle of
00:56:04.490 --> 00:56:04.870
APIs
00:56:05.530 --> 00:56:06.850
so this is
00:56:06.850 --> 00:56:07.490
a kind of
00:56:07.490 --> 00:56:08.370
most important thing
00:56:08.370 --> 00:56:09.010
when it comes to
00:56:09.010 --> 00:56:09.450
raml-based
00:56:09.450 --> 00:56:10.110
implementations
00:56:10.110 --> 00:56:10.610
so
00:56:10.610 --> 00:56:12.010
we have this
00:56:12.010 --> 00:56:12.410
expiration
00:56:12.410 --> 00:56:13.310
and non-expiration
00:56:14.890 --> 00:56:14.910
for
00:56:15.690 --> 00:56:16.250
APIs
00:56:16.250 --> 00:56:16.930
so basically
00:56:16.930 --> 00:56:17.730
APIs will be
00:56:17.730 --> 00:56:18.170
retiring
00:56:18.170 --> 00:56:19.290
on some
00:56:19.290 --> 00:56:20.050
time later
00:56:20.050 --> 00:56:20.870
so we have
00:56:20.870 --> 00:56:21.670
this convention
00:56:21.670 --> 00:56:22.070
for
00:56:22.070 --> 00:56:22.270
APIs
00:56:23.470 --> 00:56:24.570
in its whole
00:56:24.570 --> 00:56:25.110
life cycle
00:56:25.110 --> 00:56:27.490
let's say
00:56:27.490 --> 00:56:28.110
mostly
00:56:28.110 --> 00:56:28.830
like
00:56:28.830 --> 00:56:29.370
large
00:56:29.370 --> 00:56:30.070
applications
00:56:30.070 --> 00:56:30.190
or
00:56:31.850 --> 00:56:32.650
businesses
00:56:32.650 --> 00:56:33.310
who has
00:56:33.310 --> 00:56:33.470
growth
00:56:34.050 --> 00:56:35.470
associated with them
00:56:35.470 --> 00:56:35.950
their
00:56:35.950 --> 00:56:36.530
APIs will be
00:56:36.530 --> 00:56:37.370
looking like this
00:56:37.370 --> 00:56:38.810
it's a kind of
00:56:38.810 --> 00:56:39.690
development
00:56:40.810 --> 00:56:41.490
tradition
00:56:41.490 --> 00:56:42.110
you can call as
00:56:44.570 --> 00:56:45.930
and then
00:56:45.930 --> 00:56:46.690
for
00:56:46.690 --> 00:56:48.250
whether that might be
00:56:48.250 --> 00:56:48.670
catalog
00:56:50.590 --> 00:56:51.270
or
00:56:52.190 --> 00:56:52.530
so
00:56:52.530 --> 00:56:53.870
V1
00:56:53.870 --> 00:56:54.430
describes
00:56:54.430 --> 00:56:54.790
you
00:56:54.790 --> 00:56:55.470
the portion of
00:56:55.470 --> 00:56:56.470
API that you have
00:56:56.470 --> 00:56:56.810
let's say
00:56:56.810 --> 00:56:57.410
you wanted to
00:56:57.410 --> 00:56:57.830
move to
00:56:57.830 --> 00:56:58.550
V2 API
00:56:58.550 --> 00:56:59.050
and
00:56:59.050 --> 00:56:59.650
wanted to
00:56:59.650 --> 00:56:59.950
duplicate
00:56:59.950 --> 00:57:00.750
all the
00:57:00.750 --> 00:57:01.870
V1 APIs
00:57:01.870 --> 00:57:02.710
that were
00:57:02.710 --> 00:57:03.610
you know
00:57:03.610 --> 00:57:04.190
provided across
00:57:05.290 --> 00:57:06.290
to your
00:57:06.290 --> 00:57:06.630
clients
00:57:06.630 --> 00:57:07.030
or
00:57:07.030 --> 00:57:08.070
to the
00:57:08.070 --> 00:57:08.470
downstream
00:57:08.470 --> 00:57:09.430
implementations
00:57:09.430 --> 00:57:10.090
or
00:57:10.090 --> 00:57:10.610
those
00:57:10.610 --> 00:57:11.290
in those
00:57:11.290 --> 00:57:11.590
scenarios
00:57:11.590 --> 00:57:12.190
you can just
00:57:12.190 --> 00:57:12.630
deploy
00:57:12.630 --> 00:57:13.270
these
00:57:13.270 --> 00:57:13.890
V1 end points
00:57:13.890 --> 00:57:14.850
in a separate
00:57:14.850 --> 00:57:15.990
deployment aspect
00:57:15.990 --> 00:57:16.770
and again
00:57:16.770 --> 00:57:17.370
that's a
00:57:17.370 --> 00:57:18.230
architecture decision
00:57:18.230 --> 00:57:19.170
that needs to be
00:57:19.170 --> 00:57:19.550
decided
00:57:19.550 --> 00:57:20.250
of
00:57:20.250 --> 00:57:20.550
implementation
00:57:20.550 --> 00:57:21.010
I mean
00:57:21.010 --> 00:57:21.690
at the starting point
00:57:21.690 --> 00:57:22.150
of implementation
00:57:22.150 --> 00:57:22.910
but yeah
00:57:22.910 --> 00:57:23.690
this is the way
00:57:24.590 --> 00:57:25.570
APIs are
00:57:25.570 --> 00:57:26.070
organized
00:57:26.070 --> 00:57:26.530
in
00:57:27.550 --> 00:57:28.190
MuleSoft
00:57:28.190 --> 00:57:29.230
and
00:57:29.230 --> 00:57:29.530
API
00:57:29.530 --> 00:57:30.470
here
00:57:30.470 --> 00:57:31.450
when I say
00:57:31.450 --> 00:57:32.070
business
00:57:32.070 --> 00:57:34.110
that might be
00:57:34.110 --> 00:57:34.850
let's say
00:57:34.850 --> 00:57:35.410
you have
00:57:35.410 --> 00:57:36.050
a whole
00:57:36.050 --> 00:57:36.330
lot of
00:57:37.290 --> 00:57:38.310
retail systems
00:57:38.310 --> 00:57:39.430
or
00:57:39.430 --> 00:57:40.030
let's say
00:57:40.030 --> 00:57:40.350
you have
00:57:42.370 --> 00:57:42.970
maybe
00:57:42.970 --> 00:57:43.950
data warehousing
00:57:45.290 --> 00:57:46.130
business logic
00:57:46.130 --> 00:57:47.050
application as well
00:57:47.050 --> 00:57:47.950
so you'll be
00:57:47.950 --> 00:57:48.490
creating
00:57:48.490 --> 00:57:49.370
after
00:57:49.370 --> 00:57:50.350
API slash
00:57:50.350 --> 00:57:50.950
you'll be
00:57:50.950 --> 00:57:51.390
providing your
00:57:52.130 --> 00:57:53.150
business specific
00:57:53.150 --> 00:57:54.030
application
00:57:54.030 --> 00:57:54.990
to which
00:57:54.990 --> 00:57:55.630
these APIs
00:57:55.630 --> 00:57:56.530
are pointing towards
00:57:56.530 --> 00:57:57.570
so
00:57:57.570 --> 00:57:58.030
you got right
00:57:58.030 --> 00:57:58.470
so basically
00:57:58.470 --> 00:57:59.430
these are
00:57:59.430 --> 00:58:00.230
our specifications
00:58:00.230 --> 00:58:00.970
what we call
00:58:00.970 --> 00:58:02.070
this comes under
00:58:02.070 --> 00:58:03.270
a management layer
00:58:03.270 --> 00:58:04.110
so basically
00:58:04.110 --> 00:58:04.790
I mean
00:58:04.790 --> 00:58:05.370
we'll be managing
00:58:05.370 --> 00:58:05.990
the life cycle
00:58:05.990 --> 00:58:06.310
of the
00:58:06.310 --> 00:58:07.410
API as well
00:58:07.410 --> 00:58:08.230
after one
00:58:08.230 --> 00:58:08.670
or two
00:58:08.670 --> 00:58:08.970
years
00:58:10.130 --> 00:58:10.730
and
00:58:10.730 --> 00:58:11.330
providing
00:58:13.050 --> 00:58:13.650
more
00:58:13.650 --> 00:58:14.410
sophisticated
00:58:14.410 --> 00:58:14.750
APIs
00:58:14.750 --> 00:58:15.870
with the help of
00:58:15.870 --> 00:58:16.030
V2
00:58:16.650 --> 00:58:18.090
version that we
00:58:18.090 --> 00:58:18.590
release across
00:58:18.590 --> 00:58:19.350
towards the kind
00:58:20.170 --> 00:58:21.490
so that's where
00:58:21.490 --> 00:58:22.630
we'll be using
00:58:22.630 --> 00:58:23.210
raml
00:58:23.210 --> 00:58:23.790
so raml
00:58:23.790 --> 00:58:24.350
has its own
00:58:26.090 --> 00:58:26.690
specification
00:58:26.690 --> 00:58:27.090
I mean
00:58:27.090 --> 00:58:27.930
the mechanism
00:58:27.930 --> 00:58:28.430
where in which
00:58:31.730 --> 00:58:32.330
management
00:58:32.990 --> 00:58:33.750
comes into picture
00:58:33.750 --> 00:58:34.350
so we have
00:58:34.350 --> 00:58:35.110
these different layers
00:58:35.110 --> 00:58:35.470
inside the
00:58:36.330 --> 00:58:36.990
raml code
00:58:36.990 --> 00:58:38.710
that we wanted to
00:58:38.710 --> 00:58:39.190
you know
00:58:39.190 --> 00:58:39.930
manage
00:58:40.910 --> 00:58:41.810
our life cycle
00:58:41.810 --> 00:58:42.270
as well
00:58:42.270 --> 00:58:43.250
so that is
00:58:43.250 --> 00:58:44.130
the thing
00:58:44.130 --> 00:58:45.570
so once we
00:58:45.570 --> 00:58:46.030
like after
00:58:46.030 --> 00:58:46.410
this slide
00:58:46.410 --> 00:58:46.930
we'll be going
00:58:46.930 --> 00:58:47.430
into
00:58:48.410 --> 00:58:48.930
actual
00:58:48.930 --> 00:58:49.630
raml code
00:58:49.630 --> 00:58:50.170
as well
00:58:50.170 --> 00:58:50.850
so that
00:58:50.850 --> 00:58:51.930
we can have
00:58:51.930 --> 00:58:52.530
the catch on
00:58:52.530 --> 00:58:53.370
implementation experience
00:58:53.370 --> 00:58:53.890
as well as that
00:58:53.890 --> 00:58:54.990
and once
00:58:56.310 --> 00:58:57.110
all development
00:58:57.110 --> 00:58:57.710
is completed
00:58:57.710 --> 00:58:58.750
so we wanted to
00:58:59.910 --> 00:59:00.470
I mean
00:59:00.470 --> 00:59:01.210
we have developed
00:59:01.210 --> 00:59:02.130
the whole application
00:59:02.130 --> 00:59:02.470
and
00:59:02.470 --> 00:59:02.950
we want to
00:59:02.950 --> 00:59:03.430
manage that
00:59:03.430 --> 00:59:03.950
right now
00:59:03.950 --> 00:59:04.590
like we can just
00:59:06.030 --> 00:59:07.070
provide this
00:59:07.950 --> 00:59:08.470
raml
00:59:08.470 --> 00:59:09.490
specification
00:59:09.490 --> 00:59:10.210
to your
00:59:10.210 --> 00:59:10.950
downstream
00:59:11.790 --> 00:59:12.550
developers
00:59:12.550 --> 00:59:13.230
who are
00:59:13.230 --> 00:59:14.210
working on top of your
00:59:15.050 --> 00:59:15.890
integrating tool
00:59:16.850 --> 00:59:18.090
here in this case
00:59:18.090 --> 00:59:18.550
mule soft
00:59:18.550 --> 00:59:20.930
so for them
00:59:20.930 --> 00:59:21.970
we wanted to
00:59:21.970 --> 00:59:22.710
expose this
00:59:22.710 --> 00:59:24.010
specific raml code
00:59:24.010 --> 00:59:24.870
but
00:59:24.870 --> 00:59:25.650
if like
00:59:25.650 --> 00:59:26.570
you can't just
00:59:26.570 --> 00:59:27.410
expose that
00:59:27.410 --> 00:59:28.150
like creating
00:59:28.150 --> 00:59:29.070
sending an email
00:59:29.070 --> 00:59:29.750
something like that
00:59:29.750 --> 00:59:32.550
we wanted to have a
00:59:32.550 --> 00:59:33.150
sophisticated
00:59:33.150 --> 00:59:33.870
or long-term
00:59:33.870 --> 00:59:34.630
mechanism
00:59:34.630 --> 00:59:36.270
where we wanted to
00:59:36.270 --> 00:59:37.090
you know
00:59:37.090 --> 00:59:37.490
provide
00:59:37.490 --> 00:59:38.470
exporting
00:59:38.470 --> 00:59:39.270
or
00:59:39.270 --> 00:59:39.990
sharing of
00:59:40.710 --> 00:59:41.350
APS
00:59:41.350 --> 00:59:41.930
between
00:59:41.930 --> 00:59:42.950
different different
00:59:44.070 --> 00:59:45.210
implementation aspects
00:59:45.210 --> 00:59:45.990
so that's where
00:59:46.630 --> 00:59:47.350
any point
00:59:47.350 --> 00:59:48.610
exchange comes into picture
00:59:48.610 --> 00:59:49.650
here this
00:59:49.650 --> 00:59:50.590
layer itself is
00:59:50.590 --> 00:59:51.450
abstracted right now
00:59:51.450 --> 00:59:52.370
but
00:59:52.370 --> 00:59:52.810
it is
00:59:52.810 --> 00:59:53.830
this specific
00:59:54.350 --> 00:59:55.790
exchange is
00:59:55.790 --> 00:59:55.990
more
00:59:57.230 --> 00:59:58.590
specific to any point
00:59:58.590 --> 00:59:58.990
platform
00:59:58.990 --> 00:59:59.830
like
00:59:59.830 --> 01:00:00.310
let's say
01:00:00.310 --> 01:00:01.430
you wanted to have
01:00:01.430 --> 01:00:02.070
your own
01:00:02.790 --> 01:00:03.890
sharing mechanism
01:00:03.890 --> 01:00:04.470
like
01:00:04.470 --> 01:00:05.090
in that scenario
01:00:05.090 --> 01:00:06.050
you can just
01:00:06.050 --> 01:00:06.890
opt for
01:00:06.890 --> 01:00:07.570
a third party
01:00:07.570 --> 01:00:08.650
sharing mechanism as well
01:00:08.650 --> 01:00:09.810
there are lot of solutions
01:00:09.810 --> 01:00:10.370
that are there
01:00:10.370 --> 01:00:11.910
inside the market right now
01:00:11.910 --> 01:00:13.210
who provide solutions on
01:00:14.570 --> 01:00:15.170
like
01:00:15.170 --> 01:00:17.250
the API exchanges as well
01:00:17.250 --> 01:00:18.270
where you wanted to publish
01:00:18.270 --> 01:00:18.850
your APIs
01:00:18.850 --> 01:00:19.430
and
01:00:19.430 --> 01:00:20.230
they have
01:00:20.230 --> 01:00:21.950
more features on that
01:00:21.950 --> 01:00:22.490
as well like
01:00:23.150 --> 01:00:24.490
which is not exposed
01:00:24.490 --> 01:00:25.050
towards the
01:00:25.050 --> 01:00:25.790
internet
01:00:25.790 --> 01:00:27.110
so you wanted to have
01:00:27.110 --> 01:00:27.930
closed
01:00:27.930 --> 01:00:29.590
deployments for these
01:00:29.590 --> 01:00:30.610
exchange servers
01:00:30.610 --> 01:00:31.630
and all
01:00:31.630 --> 01:00:32.490
so that's where
01:00:33.070 --> 01:00:33.730
this exchange
01:00:33.730 --> 01:00:34.410
comes into picture
01:00:34.410 --> 01:00:34.870
but
01:00:34.870 --> 01:00:35.930
this exchange is
01:00:35.930 --> 01:00:36.090
more
01:00:36.970 --> 01:00:37.990
tightly coupled with
01:00:37.990 --> 01:00:38.430
the API
01:00:38.430 --> 01:00:39.450
any point platform
01:00:39.450 --> 01:00:40.390
but it is
01:00:40.390 --> 01:00:41.810
not coupled with the
01:00:41.810 --> 01:00:42.390
raml
01:00:42.390 --> 01:00:43.430
language specification
01:00:43.430 --> 01:00:44.370
raml is
01:00:44.370 --> 01:00:44.670
basically
01:00:46.930 --> 01:00:47.770
more
01:00:47.770 --> 01:00:48.710
open point
01:00:48.710 --> 01:00:49.370
or
01:00:49.370 --> 01:00:50.570
open API specification
01:00:50.570 --> 01:00:51.070
following
01:00:51.070 --> 01:00:51.950
so it's like not
01:00:53.010 --> 01:00:53.750
tightly coupled
01:00:53.750 --> 01:00:54.670
with any point
01:00:54.670 --> 01:00:55.930
so you got
01:00:56.590 --> 01:00:57.070
and then
01:00:58.550 --> 01:00:59.210
finally
01:00:59.210 --> 01:00:59.850
consumption
01:00:59.850 --> 01:01:01.830
once you expose
01:01:01.830 --> 01:01:02.530
APIs
01:01:03.710 --> 01:01:04.990
to the end user
01:01:04.990 --> 01:01:06.290
it's not
01:01:06.290 --> 01:01:07.050
I mean
01:01:07.050 --> 01:01:07.810
it's not about
01:01:07.810 --> 01:01:09.270
just exposing them
01:01:09.270 --> 01:01:10.270
and or
01:01:10.270 --> 01:01:11.310
just publishing them
01:01:11.310 --> 01:01:13.590
and they will be
01:01:13.590 --> 01:01:14.570
using that right
01:01:14.570 --> 01:01:16.510
so we wanted to provide them
01:01:16.510 --> 01:01:17.370
a consuming
01:01:17.370 --> 01:01:18.010
capabilities
01:01:18.010 --> 01:01:18.930
like
01:01:19.570 --> 01:01:21.210
they will be
01:01:21.210 --> 01:01:22.130
different different
01:01:23.010 --> 01:01:24.110
applications or systems
01:01:24.110 --> 01:01:24.930
that needs to interact
01:01:24.930 --> 01:01:26.050
with these exposed services
01:01:26.050 --> 01:01:27.950
so let's say the consumers
01:01:27.950 --> 01:01:29.010
can use this
01:01:30.450 --> 01:01:31.890
APIs that we have deployed
01:01:31.890 --> 01:01:33.010
with the help of
01:01:33.010 --> 01:01:34.290
already developed raml code
01:01:34.290 --> 01:01:35.430
so that they can just
01:01:35.430 --> 01:01:36.090
hit this API
01:01:36.090 --> 01:01:37.730
and get the details
01:01:37.810 --> 01:01:39.190
and with the help of
01:01:39.190 --> 01:01:39.630
those details
01:01:39.630 --> 01:01:40.530
they can just
01:01:40.530 --> 01:01:41.990
build a UI applications
01:01:41.990 --> 01:01:42.990
and all
01:01:42.990 --> 01:01:44.230
so this like
01:01:44.230 --> 01:01:45.750
mulesoft provides us
01:01:45.750 --> 01:01:46.950
are different API tools
01:01:46.950 --> 01:01:47.990
so that
01:01:47.990 --> 01:01:49.830
consumers can discover this
01:01:49.830 --> 01:01:51.410
and consumers can
01:01:51.970 --> 01:01:53.070
integrate it
01:01:53.070 --> 01:01:54.270
with their own
01:01:54.270 --> 01:01:54.730
APIs
01:01:54.730 --> 01:01:55.670
effectively
01:01:55.670 --> 01:01:58.230
so this
01:01:58.230 --> 01:01:59.690
raml provides that
01:01:59.690 --> 01:02:00.610
specific integrations
01:02:01.270 --> 01:02:02.130
so that's what
01:02:02.650 --> 01:02:03.830
an API
01:02:03.830 --> 01:02:05.110
in terms of
01:02:05.110 --> 01:02:06.310
mulesoft implementations
01:02:06.310 --> 01:02:07.790
so for all these
01:02:07.810 --> 01:02:08.770
definition
01:02:08.770 --> 01:02:09.530
implementation
01:02:09.530 --> 01:02:10.290
and management
01:02:10.930 --> 01:02:11.910
any point on
01:02:11.910 --> 01:02:12.770
mulesoft has its own
01:02:13.690 --> 01:02:14.770
tightly coupled
01:02:15.810 --> 01:02:17.150
solution for them
01:02:17.150 --> 01:02:17.810
so that's what
01:02:17.810 --> 01:02:18.290
we'll be going
01:02:18.830 --> 01:02:19.570
forward
01:02:19.570 --> 01:02:20.930
discuss right now
01:02:20.930 --> 01:02:21.890
that is raml
01:02:26.430 --> 01:02:27.190
so
01:02:27.190 --> 01:02:28.810
as we have already
01:02:28.810 --> 01:02:29.730
this is kind of
01:02:29.730 --> 01:02:30.350
redundant one
01:02:30.350 --> 01:02:31.650
so if you
01:02:32.270 --> 01:02:33.590
if you know about
01:02:33.590 --> 01:02:34.310
yaml based
01:02:34.310 --> 01:02:35.070
implementations
01:02:36.210 --> 01:02:37.190
you have any
01:02:37.190 --> 01:02:38.110
basic idea about
01:02:38.110 --> 01:02:39.110
a yaml
01:02:39.110 --> 01:02:39.670
format
01:02:39.670 --> 01:02:40.470
you have it or
01:02:42.430 --> 01:02:43.450
okay okay
01:02:44.550 --> 01:02:45.670
so let me
01:02:54.270 --> 01:02:56.290
so an ml is basically
01:02:56.290 --> 01:02:57.030
a kind of
01:02:59.150 --> 01:03:00.430
a serialization
01:03:00.430 --> 01:03:01.450
data serialization
01:03:01.450 --> 01:03:01.970
format
01:03:01.970 --> 01:03:03.330
so we have this
01:03:03.330 --> 01:03:04.250
json format right
01:03:04.250 --> 01:03:04.770
json format
01:03:04.770 --> 01:03:05.450
uses the
01:03:05.450 --> 01:03:06.230
calibration syntaxes
01:03:06.950 --> 01:03:08.850
so let's say
01:03:08.850 --> 01:03:09.510
here in json
01:03:09.510 --> 01:03:10.110
we have
01:03:10.110 --> 01:03:11.190
key value mechanisms
01:03:11.190 --> 01:03:13.210
so we have a key
01:03:13.210 --> 01:03:14.550
and the associated
01:03:14.550 --> 01:03:15.350
value over there
01:03:16.610 --> 01:03:17.270
separated with
01:03:17.810 --> 01:03:18.490
colon
01:03:20.470 --> 01:03:21.430
basically
01:03:21.430 --> 01:03:22.330
value
01:03:23.350 --> 01:03:25.330
and that's how
01:03:25.330 --> 01:03:26.370
almost all
01:03:26.370 --> 01:03:27.190
APIs work
01:03:27.190 --> 01:03:27.590
till now
01:03:28.310 --> 01:03:29.310
even mulesoft
01:03:29.310 --> 01:03:29.950
APIs
01:03:29.950 --> 01:03:30.790
are built
01:03:30.790 --> 01:03:31.590
with the help of
01:03:33.290 --> 01:03:33.990
this specific
01:03:34.610 --> 01:03:35.930
json based
01:03:35.930 --> 01:03:36.750
data serialization
01:03:36.750 --> 01:03:37.150
format
01:03:37.150 --> 01:03:38.370
when i say data
01:03:38.370 --> 01:03:39.510
serialization format
01:03:40.090 --> 01:03:40.550
let's say
01:03:40.550 --> 01:03:41.110
you wanted to
01:03:41.110 --> 01:03:41.590
fetch and
01:03:41.590 --> 01:03:42.230
fetch some
01:03:42.230 --> 01:03:42.750
data from
01:03:42.750 --> 01:03:43.070
database
01:03:43.070 --> 01:03:44.210
and
01:03:44.210 --> 01:03:44.690
you know
01:03:44.690 --> 01:03:45.810
broadcast this data
01:03:45.810 --> 01:03:46.650
to lot of
01:03:47.450 --> 01:03:47.930
users
01:03:47.930 --> 01:03:49.030
via this API
01:03:49.030 --> 01:03:50.430
so that's how
01:03:50.430 --> 01:03:51.010
you'll be
01:03:51.010 --> 01:03:51.670
providing data
01:03:51.670 --> 01:03:52.470
i mean the
01:03:52.470 --> 01:03:53.350
response of
01:03:53.350 --> 01:03:54.290
a specific API
01:03:54.290 --> 01:03:55.050
will
01:03:55.050 --> 01:03:55.690
should be in a
01:03:55.690 --> 01:03:56.350
format right
01:03:56.350 --> 01:03:56.890
that format
01:03:56.890 --> 01:03:57.290
is called
01:03:57.290 --> 01:03:57.850
json format
01:04:00.070 --> 01:04:01.050
and you have
01:04:02.730 --> 01:04:03.630
json inside
01:04:03.630 --> 01:04:04.010
a json
01:04:04.530 --> 01:04:05.650
so let's say
01:04:05.650 --> 01:04:06.870
multi-layer
01:04:06.870 --> 01:04:07.090
key
01:04:11.510 --> 01:04:12.570
and you can
01:04:12.570 --> 01:04:12.910
have
01:04:12.910 --> 01:04:13.330
another
01:04:13.330 --> 01:04:14.130
layer of
01:04:15.650 --> 01:04:16.330
response
01:04:16.330 --> 01:04:16.690
over here
01:04:17.590 --> 01:04:18.270
and
01:04:18.270 --> 01:04:18.630
and each
01:04:18.630 --> 01:04:19.070
and every
01:04:19.070 --> 01:04:19.310
layer
01:04:19.310 --> 01:04:19.730
should be
01:04:19.730 --> 01:04:20.010
separated
01:04:20.010 --> 01:04:21.130
with a
01:04:21.130 --> 01:04:21.370
comma
01:04:21.370 --> 01:04:22.110
over here
01:04:22.110 --> 01:04:22.890
and you
01:04:22.890 --> 01:04:23.350
can also
01:04:23.350 --> 01:04:23.710
have
01:04:23.710 --> 01:04:24.210
arrays also
01:04:24.730 --> 01:04:27.650
so let's say
01:04:32.310 --> 01:04:33.150
and you
01:04:33.150 --> 01:04:33.750
can provide
01:04:36.830 --> 01:04:37.570
comma
01:04:37.570 --> 01:04:38.270
separated values
01:04:38.270 --> 01:04:39.230
inside the array
01:04:41.270 --> 01:04:42.410
so that's
01:04:42.410 --> 01:04:42.570
how it
01:04:42.570 --> 01:04:43.230
actually works
01:04:43.230 --> 01:04:44.490
so it is
01:04:44.490 --> 01:04:45.290
json format
01:04:45.290 --> 01:04:45.790
not
01:04:45.790 --> 01:04:46.610
ml format
01:04:46.610 --> 01:04:47.090
but
01:04:47.870 --> 01:04:48.850
in order to
01:04:49.650 --> 01:04:50.110
create
01:04:50.110 --> 01:04:50.770
json
01:04:50.770 --> 01:04:51.390
responses
01:04:51.390 --> 01:04:52.050
or utilize
01:04:52.050 --> 01:04:52.950
the json responses
01:04:52.950 --> 01:04:54.070
you have to
01:04:54.070 --> 01:04:54.290
create
01:04:55.250 --> 01:04:55.990
specification
01:04:55.990 --> 01:04:56.530
an API
01:04:56.530 --> 01:04:57.290
specification
01:04:57.290 --> 01:04:58.010
use of
01:04:58.010 --> 01:04:58.290
API
01:04:58.290 --> 01:04:58.950
specification
01:04:59.950 --> 01:05:00.690
that
01:05:00.690 --> 01:05:01.550
way to
01:05:01.550 --> 01:05:01.750
create
01:05:01.750 --> 01:05:02.110
a
01:05:02.110 --> 01:05:02.570
specification
01:05:02.570 --> 01:05:03.190
is with
01:05:03.190 --> 01:05:03.390
the help
01:05:03.390 --> 01:05:03.630
of
01:05:03.630 --> 01:05:03.910
ml
01:05:04.610 --> 01:05:05.270
so
01:05:05.650 --> 01:05:06.570
when i say
01:05:06.570 --> 01:05:06.970
ml
01:05:06.970 --> 01:05:07.790
it's
01:05:07.790 --> 01:05:08.570
basically
01:05:09.810 --> 01:05:10.330
format
01:05:10.330 --> 01:05:10.710
of
01:05:10.710 --> 01:05:11.010
data
01:05:15.970 --> 01:05:16.370
so
01:05:16.890 --> 01:05:17.490
ml
01:05:17.490 --> 01:05:17.890
basically
01:05:17.890 --> 01:05:18.410
uses
01:05:19.750 --> 01:05:20.670
white
01:05:20.670 --> 01:05:21.330
space
01:05:21.330 --> 01:05:21.650
sensitive
01:05:22.770 --> 01:05:22.930
data
01:05:23.690 --> 01:05:24.170
mechanism
01:05:24.170 --> 01:05:24.470
i mean
01:05:24.470 --> 01:05:24.750
data
01:05:24.750 --> 01:05:25.110
implementation
01:05:25.110 --> 01:05:25.570
mechanism
01:05:25.570 --> 01:05:26.290
so
01:05:26.290 --> 01:05:26.850
let's say
01:05:26.850 --> 01:05:27.730
you have
01:05:27.730 --> 01:05:28.270
key
01:05:28.850 --> 01:05:29.590
and
01:05:29.590 --> 01:05:30.430
it
01:05:30.430 --> 01:05:31.070
should be
01:05:31.070 --> 01:05:31.390
separated
01:05:31.390 --> 01:05:31.850
with a
01:05:31.850 --> 01:05:32.250
space
01:05:32.250 --> 01:05:32.610
after
01:05:32.610 --> 01:05:32.990
colon
01:05:33.490 --> 01:05:34.390
and then
01:05:34.390 --> 01:05:34.890
value
01:05:35.650 --> 01:05:36.410
don't have
01:05:36.410 --> 01:05:37.130
the burden to
01:05:37.130 --> 01:05:37.790
maintain all
01:05:37.790 --> 01:05:37.810
these
01:05:38.830 --> 01:05:39.530
curly braces
01:05:39.530 --> 01:05:40.110
and
01:05:40.110 --> 01:05:40.430
codes
01:05:40.430 --> 01:05:40.930
and all
01:05:41.490 --> 01:05:41.970
which is
01:05:42.990 --> 01:05:43.350
very
01:05:43.350 --> 01:05:43.750
tiresome
01:05:43.750 --> 01:05:44.230
to type
01:05:44.230 --> 01:05:44.790
and tiresome
01:05:44.790 --> 01:05:45.330
to maintain
01:05:45.330 --> 01:05:46.150
so
01:05:46.150 --> 01:05:46.850
this ml is
01:05:47.570 --> 01:05:47.990
easy
01:05:47.990 --> 01:05:48.670
for
01:05:48.670 --> 01:05:48.990
humans
01:05:48.990 --> 01:05:49.830
to understand
01:05:49.830 --> 01:05:50.330
and
01:05:50.330 --> 01:05:50.990
act upon
01:05:51.810 --> 01:05:52.830
and similarly
01:05:52.830 --> 01:05:53.450
you have
01:05:53.450 --> 01:05:53.870
this
01:05:53.870 --> 01:05:54.630
key to
01:05:54.630 --> 01:05:55.170
and
01:05:55.170 --> 01:05:55.810
multi-layered
01:05:58.510 --> 01:05:59.030
ml
01:05:59.030 --> 01:05:59.570
based
01:05:59.570 --> 01:06:00.390
keys
01:06:00.930 --> 01:06:01.230
so
01:06:01.230 --> 01:06:01.790
for this
01:06:01.790 --> 01:06:02.210
multi-layered
01:06:03.070 --> 01:06:03.610
ml based
01:06:03.610 --> 01:06:04.150
keys
01:06:04.850 --> 01:06:05.290
front
01:06:05.290 --> 01:06:06.010
space should be
01:06:06.950 --> 01:06:07.630
there
01:06:10.750 --> 01:06:11.430
so
01:06:14.750 --> 01:06:16.230
so that's how this works
01:06:16.230 --> 01:06:17.070
and
01:06:17.070 --> 01:06:17.890
for
01:06:17.890 --> 01:06:18.390
arrays
01:06:18.390 --> 01:06:19.630
we have separate syntax
01:06:19.630 --> 01:06:20.410
in yaml
01:06:20.410 --> 01:06:22.150
so let's say
01:06:25.970 --> 01:06:27.310
this is a pipe
01:06:27.310 --> 01:06:28.670
which is on top of enter
01:06:29.810 --> 01:06:30.490
and
01:06:30.490 --> 01:06:31.870
we can just provide
01:06:31.870 --> 01:06:32.870
a list here
01:06:32.870 --> 01:06:33.510
a multi-line
01:06:33.510 --> 01:06:34.210
command also
01:06:34.210 --> 01:06:34.990
but
01:06:34.990 --> 01:06:35.790
yaml
01:06:35.790 --> 01:06:36.570
doesn't
01:06:36.570 --> 01:06:37.190
provide you
01:06:37.190 --> 01:06:37.750
support for
01:06:37.750 --> 01:06:38.070
multi-line
01:06:38.070 --> 01:06:38.410
commands
01:06:39.090 --> 01:06:40.110
in order to
01:06:40.110 --> 01:06:40.970
tell yaml that
01:06:41.970 --> 01:06:42.790
I do have an
01:06:42.790 --> 01:06:43.910
array over here
01:06:43.910 --> 01:06:44.290
and
01:06:44.290 --> 01:06:45.050
I wanted to
01:06:45.050 --> 01:06:45.730
provide multiple
01:06:47.290 --> 01:06:48.690
number of
01:06:48.690 --> 01:06:49.810
layers over here
01:06:49.810 --> 01:06:50.570
I mean multiple
01:06:50.570 --> 01:06:50.850
number of
01:06:51.970 --> 01:06:52.250
keys
01:06:52.250 --> 01:06:52.850
or values
01:06:52.850 --> 01:06:53.590
over here
01:06:53.590 --> 01:06:53.890
so that
01:06:54.570 --> 01:06:54.990
yaml
01:06:54.990 --> 01:06:55.650
understands that
01:06:56.270 --> 01:06:57.210
this pipe symbol
01:06:57.210 --> 01:06:58.410
responsible for that
01:06:58.410 --> 01:06:59.310
so you will be
01:06:59.310 --> 01:06:59.870
providing
01:07:01.630 --> 01:07:02.950
value one
01:07:02.950 --> 01:07:03.670
and then
01:07:05.010 --> 01:07:06.250
so the white space
01:07:06.250 --> 01:07:06.610
should be
01:07:06.610 --> 01:07:07.530
most important here
01:07:07.530 --> 01:07:08.310
so that
01:07:08.310 --> 01:07:09.390
it understands
01:07:09.390 --> 01:07:10.270
where this array
01:07:10.270 --> 01:07:10.710
stops
01:07:10.710 --> 01:07:11.770
and
01:07:11.770 --> 01:07:12.950
what is the next
01:07:15.150 --> 01:07:16.070
key over here
01:07:21.270 --> 01:07:22.290
so you can see
01:07:22.290 --> 01:07:22.430
right
01:07:22.430 --> 01:07:23.070
if the
01:07:23.070 --> 01:07:23.550
the differences
01:07:23.550 --> 01:07:24.150
between these
01:07:25.850 --> 01:07:26.750
white space
01:07:26.750 --> 01:07:27.230
and
01:07:27.230 --> 01:07:28.050
yeah key three
01:07:28.050 --> 01:07:29.250
and this is
01:07:29.250 --> 01:07:29.870
one of the way
01:07:29.870 --> 01:07:30.530
where you provide
01:07:30.530 --> 01:07:31.030
an array
01:07:31.030 --> 01:07:32.230
and the other way
01:07:32.230 --> 01:07:32.730
is to
01:07:34.750 --> 01:07:35.550
have
01:07:36.230 --> 01:07:36.750
whole
01:07:36.750 --> 01:07:37.770
like
01:07:37.770 --> 01:07:38.330
minor symbols
01:07:38.330 --> 01:07:38.910
basically
01:07:41.950 --> 01:07:42.950
this is
01:07:42.950 --> 01:07:43.450
more
01:07:43.450 --> 01:07:44.390
user-friendly one
01:07:47.750 --> 01:07:49.050
key three
01:07:49.050 --> 01:07:49.990
et cetera
01:07:49.990 --> 01:07:51.190
so that's how
01:07:51.190 --> 01:07:51.650
a basic
01:07:51.650 --> 01:07:52.650
ML syntax works
01:07:52.650 --> 01:07:53.730
maybe while
01:07:53.730 --> 01:07:54.710
we go on
01:07:55.490 --> 01:07:56.010
while
01:07:56.010 --> 01:07:56.510
developing
01:07:56.510 --> 01:07:57.190
this yaml
01:07:57.190 --> 01:07:57.410
or
01:07:57.410 --> 01:07:58.070
raml-based
01:07:58.950 --> 01:07:59.390
things
01:07:59.390 --> 01:08:00.190
it will be
01:08:00.190 --> 01:08:01.230
easy for us to
01:08:02.310 --> 01:08:02.990
get things
01:08:02.990 --> 01:08:03.610
going on
01:08:04.570 --> 01:08:06.470
so that's how
01:08:06.470 --> 01:08:07.070
it uses
01:08:07.070 --> 01:08:07.550
it so basically
01:08:07.550 --> 01:08:07.830
it uses
01:08:08.830 --> 01:08:09.750
yaml-based
01:08:10.330 --> 01:08:11.130
mechanisms
01:08:12.150 --> 01:08:14.070
and apart from that
01:08:14.710 --> 01:08:15.190
how this
01:08:16.670 --> 01:08:17.830
API design
01:08:17.830 --> 01:08:18.650
will be doing
01:08:19.810 --> 01:08:20.650
so
01:08:21.670 --> 01:08:22.790
if you understand
01:08:22.790 --> 01:08:23.610
REST APIs
01:08:23.610 --> 01:08:24.650
so basically
01:08:24.650 --> 01:08:25.310
REST APIs
01:08:25.310 --> 01:08:25.710
provides
01:08:25.710 --> 01:08:27.810
as I have already told you
01:08:27.810 --> 01:08:28.970
this REST APIs
01:08:28.970 --> 01:08:29.890
basically
01:08:29.890 --> 01:08:30.630
whatever
01:08:33.130 --> 01:08:34.870
the state of system
01:08:34.870 --> 01:08:35.630
before
01:08:35.630 --> 01:08:36.550
calling an API
01:08:36.550 --> 01:08:38.210
and the state of system
01:08:38.210 --> 01:08:39.210
after the calling an API
01:08:39.210 --> 01:08:40.090
it should be same
01:08:40.090 --> 01:08:41.630
that is the hard rule
01:08:41.630 --> 01:08:43.030
for this REST APIs
01:08:43.030 --> 01:08:43.910
basically
01:08:43.910 --> 01:08:45.170
so we wanted to
01:08:45.950 --> 01:08:46.590
implement
01:08:46.590 --> 01:08:47.870
APIs
01:08:47.870 --> 01:08:50.250
that is like
01:08:50.870 --> 01:08:52.030
binding to that
01:08:52.030 --> 01:08:52.670
REST API
01:08:52.670 --> 01:08:53.390
specifications
01:08:53.390 --> 01:08:54.990
so that's first and foremost
01:08:54.990 --> 01:08:55.870
important thing
01:08:55.870 --> 01:08:56.950
in those REST APIs
01:08:56.950 --> 01:08:57.630
we have
01:08:57.630 --> 01:08:58.250
resources
01:08:58.250 --> 01:08:58.870
methods
01:08:58.870 --> 01:08:59.410
requests
01:08:59.410 --> 01:09:00.450
and response schemas
01:09:00.450 --> 01:09:01.930
we'll be going over them
01:09:01.930 --> 01:09:02.430
right now
01:09:02.430 --> 01:09:03.250
so it requires
01:09:03.970 --> 01:09:04.970
much more deep dive
01:09:06.270 --> 01:09:06.830
into
01:09:06.830 --> 01:09:08.330
API based implementations
01:09:08.330 --> 01:09:08.450
so
01:09:09.730 --> 01:09:11.290
feel free to
01:09:11.290 --> 01:09:11.890
stop me
01:09:12.690 --> 01:09:13.650
if you don't understand
01:09:17.410 --> 01:09:17.970
and
01:09:17.970 --> 01:09:18.530
and method
01:09:19.310 --> 01:09:20.350
so method is
01:09:20.350 --> 01:09:20.850
basically like
01:09:22.070 --> 01:09:23.170
an REST API method
01:09:23.170 --> 01:09:24.530
so it has
01:09:24.530 --> 01:09:25.330
as I have already told
01:09:25.330 --> 01:09:26.350
these are REST API methods
01:09:26.350 --> 01:09:27.290
you can just
01:09:27.290 --> 01:09:28.490
use this method
01:09:28.490 --> 01:09:30.430
or fetch things
01:09:30.450 --> 01:09:31.910
with the help of API
01:09:31.910 --> 01:09:33.830
so that user can understand
01:09:33.830 --> 01:09:35.130
what this API does
01:09:35.130 --> 01:09:35.490
whether
01:09:36.270 --> 01:09:37.970
a user needs to push
01:09:37.970 --> 01:09:38.450
data into
01:09:39.270 --> 01:09:39.870
server
01:09:39.870 --> 01:09:40.850
with the help of
01:09:40.850 --> 01:09:41.370
post API
01:09:41.370 --> 01:09:42.230
or put API
01:09:42.230 --> 01:09:44.010
or user wants to delete
01:09:44.010 --> 01:09:44.930
a specific entry
01:09:44.930 --> 01:09:45.690
inside the database
01:09:45.690 --> 01:09:46.390
with the help of
01:09:46.390 --> 01:09:47.270
delete API
01:09:47.270 --> 01:09:48.310
patch API
01:09:48.310 --> 01:09:49.210
basically does
01:09:49.210 --> 01:09:50.890
a modification of a resource
01:09:50.890 --> 01:09:52.510
inside the database system
01:09:52.510 --> 01:09:54.270
so that's what
01:09:54.270 --> 01:09:56.330
patch API is responsible for
01:09:56.330 --> 01:09:57.510
and get API
01:09:57.510 --> 01:09:58.610
is like responsible for
01:10:01.110 --> 01:10:02.230
getting the data
01:10:02.230 --> 01:10:02.530
from the
01:10:03.710 --> 01:10:05.070
actual system
01:10:05.070 --> 01:10:06.570
webinar system
01:10:06.570 --> 01:10:08.390
it's database system
01:10:08.390 --> 01:10:08.850
which is
01:10:09.970 --> 01:10:10.290
sits on
01:10:11.350 --> 01:10:12.770
the end most layer
01:10:12.770 --> 01:10:13.910
of the
01:10:13.910 --> 01:10:15.570
MuleSoft implementations
01:10:15.570 --> 01:10:16.530
for MuleSoft
01:10:16.530 --> 01:10:17.230
we will be interacting
01:10:17.230 --> 01:10:17.890
with the database
01:10:18.450 --> 01:10:19.030
okay
01:10:19.030 --> 01:10:20.210
so we'll be pushing these
01:10:23.230 --> 01:10:23.910
methods
01:10:23.910 --> 01:10:24.670
API methods
01:10:24.670 --> 01:10:26.270
to business logic layer
01:10:26.270 --> 01:10:26.770
which
01:10:27.490 --> 01:10:29.030
takes care of by MuleSoft
01:10:29.030 --> 01:10:29.570
and then
01:10:29.830 --> 01:10:30.830
at the end
01:10:30.830 --> 01:10:32.150
the database is the one
01:10:32.150 --> 01:10:33.650
which persistently stores
01:10:33.650 --> 01:10:34.670
all the data
01:10:34.670 --> 01:10:35.510
and
01:10:35.510 --> 01:10:36.110
serves us
01:10:36.110 --> 01:10:36.470
basically
01:10:37.110 --> 01:10:38.630
so that's how it works
01:10:38.630 --> 01:10:39.190
that is
01:10:40.150 --> 01:10:41.090
API method
01:10:41.090 --> 01:10:41.670
basically
01:10:43.190 --> 01:10:43.830
and
01:10:43.830 --> 01:10:45.370
we wanted to provide
01:10:45.370 --> 01:10:46.150
a payload
01:10:46.150 --> 01:10:47.030
to a method right
01:10:47.030 --> 01:10:48.270
so let's say
01:10:48.270 --> 01:10:49.350
a forget request
01:10:49.350 --> 01:10:49.970
you don't need to
01:10:49.970 --> 01:10:50.670
provide a payload
01:10:50.670 --> 01:10:51.810
but for
01:10:51.810 --> 01:10:52.310
let's say
01:10:52.310 --> 01:10:53.030
patch request
01:10:53.030 --> 01:10:53.990
or post request
01:10:53.990 --> 01:10:54.670
need to provide
01:10:54.670 --> 01:10:55.530
some kind of payload
01:10:55.530 --> 01:10:55.910
for that
01:10:56.690 --> 01:10:57.190
request
01:10:57.190 --> 01:10:58.770
so what this payload
01:10:58.770 --> 01:10:59.810
exactly is
01:11:00.470 --> 01:11:00.950
that
01:11:03.450 --> 01:11:03.930
so
01:11:03.930 --> 01:11:04.530
let's say
01:11:04.530 --> 01:11:05.610
you wanted to have
01:11:05.610 --> 01:11:06.650
I mean you have created
01:11:06.650 --> 01:11:07.630
a product implementation
01:11:07.630 --> 01:11:09.190
and for this product
01:11:09.190 --> 01:11:10.550
raml implementation
01:11:11.790 --> 01:11:12.870
you wanted to create
01:11:12.870 --> 01:11:13.470
a new product
01:11:13.470 --> 01:11:14.210
for your catalog
01:11:15.110 --> 01:11:15.590
and
01:11:15.590 --> 01:11:16.470
you don't want to
01:11:16.470 --> 01:11:17.510
go to API
01:11:17.510 --> 01:11:17.870
sorry
01:11:17.870 --> 01:11:18.450
you don't want to
01:11:18.450 --> 01:11:19.110
go to database
01:11:19.110 --> 01:11:19.830
and
01:11:19.830 --> 01:11:21.550
load database query languages
01:11:21.550 --> 01:11:23.070
and interact with the database
01:11:23.070 --> 01:11:24.430
you just kind of
01:11:24.430 --> 01:11:25.130
created
01:11:26.070 --> 01:11:26.550
API
01:11:26.550 --> 01:11:27.590
and provided that
01:11:27.590 --> 01:11:28.310
to your consumers
01:11:28.810 --> 01:11:29.290
and
01:11:29.290 --> 01:11:30.870
whatever the product catalog
01:11:30.870 --> 01:11:31.830
let's say
01:11:31.830 --> 01:11:32.750
details
01:11:33.730 --> 01:11:33.770
regarding
01:11:34.850 --> 01:11:35.830
product like
01:11:35.830 --> 01:11:37.010
the product name
01:11:38.450 --> 01:11:39.810
if you can see here
01:11:39.810 --> 01:11:40.430
we'll be using
01:11:40.430 --> 01:11:41.370
JSON syntax over here
01:11:44.690 --> 01:11:47.150
so that's how
01:11:47.150 --> 01:11:48.210
API specification
01:11:48.210 --> 01:11:49.210
works basically
01:11:49.210 --> 01:11:50.330
it describes us
01:11:50.950 --> 01:11:52.010
what are the fields
01:11:52.010 --> 01:11:53.330
that you have to provide
01:11:53.850 --> 01:11:55.050
so API specification
01:11:55.050 --> 01:11:55.490
provides
01:11:55.490 --> 01:11:56.330
what are the fields
01:11:56.330 --> 01:11:57.190
that you need to provide
01:11:57.190 --> 01:11:58.070
inside the payload
01:11:58.070 --> 01:11:59.470
here inside the payload
01:11:59.470 --> 01:12:00.310
I provided
01:12:00.310 --> 01:12:00.990
product name
01:12:00.990 --> 01:12:01.890
that is
01:12:01.890 --> 01:12:02.730
the compulsory
01:12:02.730 --> 01:12:03.870
or the mandatory field
01:12:03.870 --> 01:12:04.630
that you have to provide
01:12:04.630 --> 01:12:05.430
you can also
01:12:05.430 --> 01:12:06.470
design your
01:12:06.470 --> 01:12:06.950
API
01:12:06.950 --> 01:12:07.770
you know
01:12:07.770 --> 01:12:08.390
to provide you
01:12:08.910 --> 01:12:09.790
I mean
01:12:09.790 --> 01:12:10.850
so that you can
01:12:10.850 --> 01:12:11.330
you know
01:12:11.330 --> 01:12:11.990
have
01:12:11.990 --> 01:12:12.390
optional
01:12:13.130 --> 01:12:13.750
fields
01:12:13.750 --> 01:12:14.750
inside your application
01:12:14.750 --> 01:12:15.030
and all
01:12:16.810 --> 01:12:17.430
so
01:12:17.430 --> 01:12:18.390
optional field one
01:12:28.160 --> 01:12:29.500
at the end
01:12:29.500 --> 01:12:30.120
we'll be having
01:12:30.120 --> 01:12:30.800
a serialization
01:12:30.800 --> 01:12:31.660
closing
01:12:31.660 --> 01:12:32.340
syntax
01:12:33.440 --> 01:12:34.340
which is
01:12:34.340 --> 01:12:34.900
the flower bracket
01:12:34.900 --> 01:12:36.200
so this is
01:12:36.200 --> 01:12:36.580
a payload
01:12:36.580 --> 01:12:37.760
so we'll be passing
01:12:37.760 --> 01:12:38.420
this specific
01:12:38.420 --> 01:12:38.780
payload
01:12:38.780 --> 01:12:39.860
to the API
01:12:39.860 --> 01:12:41.180
for post request
01:12:41.180 --> 01:12:41.700
or
01:12:41.700 --> 01:12:42.840
for delete request
01:12:42.840 --> 01:12:43.000
or
01:12:43.800 --> 01:12:44.600
patch request
01:12:44.600 --> 01:12:46.060
so that's how it works
01:12:46.060 --> 01:12:46.600
basically
01:12:46.600 --> 01:12:47.560
when you wanted to
01:12:47.560 --> 01:12:48.120
create a product
01:12:48.120 --> 01:12:49.560
you will be passing this
01:12:49.560 --> 01:12:50.700
you in the sense
01:12:50.700 --> 01:12:51.400
end user
01:12:51.400 --> 01:12:52.160
but
01:12:52.160 --> 01:12:53.280
what is your task
01:12:53.280 --> 01:12:53.840
for here
01:12:53.840 --> 01:12:54.880
wanted to design
01:12:55.460 --> 01:12:56.020
how
01:12:56.020 --> 01:12:56.660
a payload
01:12:56.660 --> 01:12:57.500
should look like
01:12:57.500 --> 01:12:58.480
so that
01:12:58.480 --> 01:12:59.420
is the
01:12:59.420 --> 01:13:00.160
end goal
01:13:00.160 --> 01:13:01.300
of us to
01:13:01.300 --> 01:13:01.680
understand
01:13:01.680 --> 01:13:02.740
how this all works
01:13:02.740 --> 01:13:03.520
so basically
01:13:03.520 --> 01:13:04.560
we will be designing
01:13:05.320 --> 01:13:06.740
how a method should be
01:13:06.740 --> 01:13:07.960
how a request should be
01:13:07.960 --> 01:13:09.220
how a payload should be
01:13:09.220 --> 01:13:10.820
how a response should be
01:13:10.820 --> 01:13:12.260
that's how
01:13:12.260 --> 01:13:13.160
we'll be designing
01:13:14.180 --> 01:13:15.300
API specification
01:13:16.120 --> 01:13:16.400
and
01:13:16.400 --> 01:13:17.740
when it comes to
01:13:18.520 --> 01:13:19.200
headers
01:13:20.080 --> 01:13:20.760
so
01:13:20.760 --> 01:13:22.380
let's say
01:13:23.080 --> 01:13:24.100
you have implemented
01:13:24.100 --> 01:13:24.780
an authorization
01:13:24.780 --> 01:13:25.300
mechanism
01:13:25.300 --> 01:13:26.220
for your application
01:13:26.220 --> 01:13:27.240
and this
01:13:27.240 --> 01:13:28.020
authorization mechanism
01:13:28.020 --> 01:13:28.420
uses
01:13:28.420 --> 01:13:29.000
OAuth 2
01:13:29.600 --> 01:13:30.680
as a
01:13:30.680 --> 01:13:31.000
standard
01:13:31.000 --> 01:13:31.880
authorization mechanism
01:13:31.880 --> 01:13:32.440
and you have
01:13:32.440 --> 01:13:33.000
access control
01:13:33.620 --> 01:13:34.400
role-based
01:13:34.400 --> 01:13:35.180
access control
01:13:36.060 --> 01:13:36.740
and
01:13:36.740 --> 01:13:37.600
private keys
01:13:37.600 --> 01:13:38.140
public keys
01:13:38.140 --> 01:13:38.920
mechanisms
01:13:39.900 --> 01:13:40.580
and
01:13:40.580 --> 01:13:41.300
JWT tokens
01:13:41.300 --> 01:13:42.000
as one of the
01:13:42.000 --> 01:13:42.380
mechanism
01:13:42.380 --> 01:13:43.560
so all these things
01:13:44.360 --> 01:13:45.040
whenever
01:13:45.040 --> 01:13:45.500
let's say
01:13:45.500 --> 01:13:46.000
a person
01:13:46.000 --> 01:13:46.580
makes a request
01:13:46.580 --> 01:13:47.640
to the
01:13:47.640 --> 01:13:47.960
client
01:13:48.680 --> 01:13:49.500
a client
01:13:49.500 --> 01:13:50.220
makes a request
01:13:50.220 --> 01:13:51.060
to the server
01:13:51.060 --> 01:13:52.260
he needs to
01:13:52.260 --> 01:13:52.680
pass his
01:13:53.280 --> 01:13:54.460
he needs to
01:13:54.460 --> 01:13:54.940
pass his
01:13:54.940 --> 01:13:55.680
user identification
01:13:55.680 --> 01:13:56.740
so that
01:13:56.740 --> 01:13:57.360
the
01:13:57.360 --> 01:13:57.720
server can
01:13:58.520 --> 01:13:59.800
make sure
01:13:59.800 --> 01:14:00.040
that
01:14:00.940 --> 01:14:01.720
to validate him
01:14:03.800 --> 01:14:04.880
to understand
01:14:04.880 --> 01:14:06.420
who he is
01:14:06.420 --> 01:14:07.120
basically
01:14:07.880 --> 01:14:08.560
so in those
01:14:08.560 --> 01:14:09.040
scenarios
01:14:09.040 --> 01:14:09.960
we can't just
01:14:09.960 --> 01:14:10.340
provide them
01:14:10.340 --> 01:14:11.060
as a payload
01:14:11.060 --> 01:14:12.100
because payload
01:14:12.100 --> 01:14:13.000
is
01:14:13.000 --> 01:14:13.320
basically
01:14:13.880 --> 01:14:14.900
can be
01:14:15.720 --> 01:14:17.080
they should be
01:14:17.080 --> 01:14:17.740
transmitted over
01:14:17.740 --> 01:14:18.960
network across
01:14:18.960 --> 01:14:19.480
different
01:14:19.480 --> 01:14:20.360
backbone layers
01:14:20.360 --> 01:14:21.040
or
01:14:21.040 --> 01:14:21.740
backbone networks
01:14:21.740 --> 01:14:22.340
where users
01:14:22.340 --> 01:14:23.180
doesn't have any
01:14:23.180 --> 01:14:23.720
control over
01:14:23.720 --> 01:14:24.480
so
01:14:24.480 --> 01:14:24.720
headers
01:14:24.720 --> 01:14:25.480
comes into picture
01:14:25.480 --> 01:14:26.040
for that
01:14:26.040 --> 01:14:26.800
specific scenarios
01:14:26.800 --> 01:14:27.640
so basically
01:14:27.640 --> 01:14:27.960
headers
01:14:27.960 --> 01:14:28.820
consists of
01:14:28.820 --> 01:14:29.440
all these
01:14:29.440 --> 01:14:30.400
sensitive data
01:14:30.400 --> 01:14:31.120
like the
01:14:31.120 --> 01:14:31.580
authentication
01:14:31.580 --> 01:14:32.460
and authorizations
01:14:34.500 --> 01:14:35.220
or
01:14:35.220 --> 01:14:36.160
implementations
01:14:36.160 --> 01:14:37.220
or
01:14:37.220 --> 01:14:37.840
public and
01:14:37.840 --> 01:14:38.800
private keys
01:14:42.300 --> 01:14:43.020
or
01:14:43.020 --> 01:14:44.780
let's say
01:14:44.780 --> 01:14:45.720
access control
01:14:45.720 --> 01:14:46.140
mechanism
01:14:46.140 --> 01:14:47.100
like access keys
01:14:47.100 --> 01:14:47.620
or
01:14:47.620 --> 01:14:48.620
refresh tokens
01:14:49.780 --> 01:14:50.380
or
01:14:50.380 --> 01:14:51.240
JWT tokens
01:14:51.240 --> 01:14:52.400
so these are
01:14:52.400 --> 01:14:52.740
a couple of
01:14:54.420 --> 01:14:55.780
ways to interact
01:14:55.780 --> 01:14:56.380
or
01:14:56.380 --> 01:14:56.780
ways to
01:14:56.780 --> 01:14:57.060
authenticate
01:14:58.020 --> 01:14:58.620
between
01:14:59.720 --> 01:15:00.320
different
01:15:00.320 --> 01:15:00.760
different
01:15:00.760 --> 01:15:01.080
API
01:15:01.080 --> 01:15:01.660
implementations
01:15:01.660 --> 01:15:01.960
okay
01:15:01.960 --> 01:15:02.920
so that's how
01:15:02.920 --> 01:15:03.360
the headers
01:15:03.360 --> 01:15:03.720
work
01:15:03.720 --> 01:15:04.700
and
01:15:04.700 --> 01:15:05.120
user can
01:15:05.120 --> 01:15:05.380
also
01:15:05.380 --> 01:15:05.700
create
01:15:05.700 --> 01:15:06.320
custom headers
01:15:06.320 --> 01:15:06.820
also
01:15:06.820 --> 01:15:07.800
so what
01:15:07.800 --> 01:15:08.200
is the
01:15:08.200 --> 01:15:08.580
structure of
01:15:08.580 --> 01:15:09.140
a custom header
01:15:09.140 --> 01:15:09.660
you wanted
01:15:09.660 --> 01:15:10.320
to describe
01:15:10.320 --> 01:15:10.900
that
01:15:10.900 --> 01:15:11.300
with the
01:15:11.300 --> 01:15:11.680
help of
01:15:11.680 --> 01:15:11.840
your
01:15:11.840 --> 01:15:12.680
mule soft
01:15:12.680 --> 01:15:13.360
raml
01:15:13.360 --> 01:15:13.920
implementation
01:15:13.920 --> 01:15:15.040
so that's
01:15:15.040 --> 01:15:15.380
how
01:15:15.380 --> 01:15:16.100
you will be
01:15:16.100 --> 01:15:16.500
defining
01:15:16.500 --> 01:15:17.380
what are
01:15:17.380 --> 01:15:17.600
the
01:15:17.620 --> 01:15:18.620
required
01:15:18.620 --> 01:15:19.020
headers
01:15:19.020 --> 01:15:19.600
and
01:15:19.600 --> 01:15:20.120
what is the
01:15:20.120 --> 01:15:20.460
syntax
01:15:20.460 --> 01:15:20.920
of those
01:15:20.920 --> 01:15:21.380
headers
01:15:21.380 --> 01:15:22.400
you wanted
01:15:22.400 --> 01:15:22.960
to pass
01:15:22.960 --> 01:15:23.580
and all
01:15:23.580 --> 01:15:24.440
so that's
01:15:24.440 --> 01:15:24.720
how it
01:15:24.720 --> 01:15:24.900
works
01:15:24.900 --> 01:15:25.520
basically
01:15:27.100 --> 01:15:27.700
okay
01:15:27.700 --> 01:15:28.120
yeah
01:15:28.120 --> 01:15:28.880
and then
01:15:28.880 --> 01:15:29.500
the response
01:15:29.500 --> 01:15:29.960
schemas
01:15:29.960 --> 01:15:30.480
this is the
01:15:30.480 --> 01:15:31.040
one of the
01:15:31.040 --> 01:15:31.260
most
01:15:31.260 --> 01:15:31.720
important
01:15:31.720 --> 01:15:31.860
thing
01:15:32.780 --> 01:15:33.560
that we
01:15:33.560 --> 01:15:34.440
wanted to
01:15:34.440 --> 01:15:34.860
understand
01:15:34.860 --> 01:15:35.060
about
01:15:35.900 --> 01:15:36.500
implementation
01:15:36.500 --> 01:15:37.380
let's say
01:15:37.380 --> 01:15:38.160
I'll be just
01:15:38.160 --> 01:15:40.420
pasting you
01:15:40.420 --> 01:15:41.380
implementation
01:15:41.380 --> 01:15:41.940
example
01:15:41.940 --> 01:15:42.480
which is
01:15:43.420 --> 01:15:44.260
till now
01:15:44.260 --> 01:15:44.800
I've described
01:15:44.800 --> 01:15:45.200
you the
01:15:45.200 --> 01:15:45.600
response
01:15:45.600 --> 01:15:45.900
response
01:15:45.900 --> 01:15:46.260
response
01:15:46.260 --> 01:15:46.700
and write
01:15:46.700 --> 01:15:47.200
so what
01:15:47.200 --> 01:15:47.420
exactly
01:15:47.420 --> 01:15:47.660
is this
01:15:47.660 --> 01:15:48.000
response
01:15:48.700 --> 01:15:48.980
so if
01:15:48.980 --> 01:15:49.420
you go
01:15:49.420 --> 01:15:49.920
here
01:15:49.920 --> 01:15:50.700
this is
01:15:50.700 --> 01:15:51.020
by the way
01:15:51.020 --> 01:15:51.340
this is
01:15:51.340 --> 01:15:52.200
a sample
01:15:52.200 --> 01:15:53.060
or raml
01:15:53.060 --> 01:15:53.200
file
01:15:53.200 --> 01:15:53.800
okay
01:15:53.800 --> 01:15:55.200
so basically
01:15:55.200 --> 01:15:55.920
it consists
01:15:55.920 --> 01:15:56.380
of
01:15:57.060 --> 01:15:57.960
what is
01:15:57.960 --> 01:15:59.040
the
01:15:59.040 --> 01:15:59.700
actual end
01:15:59.700 --> 01:15:59.980
users
01:15:59.980 --> 01:16:00.640
that this
01:16:00.640 --> 01:16:01.420
has
01:16:02.140 --> 01:16:02.500
for this
01:16:02.500 --> 01:16:03.300
we have
01:16:03.300 --> 01:16:03.640
retail
01:16:03.640 --> 01:16:04.020
products
01:16:04.020 --> 01:16:04.540
that we
01:16:04.540 --> 01:16:04.920
have
01:16:04.920 --> 01:16:05.340
like the
01:16:05.340 --> 01:16:05.760
list of
01:16:05.760 --> 01:16:06.220
products
01:16:06.220 --> 01:16:06.920
a specific
01:16:06.920 --> 01:16:07.260
catalog
01:16:07.260 --> 01:16:07.680
has
01:16:07.680 --> 01:16:08.420
and the
01:16:08.420 --> 01:16:08.860
retail tags
01:16:08.860 --> 01:16:09.080
on
01:16:09.080 --> 01:16:10.200
as well
01:16:10.940 --> 01:16:11.240
so
01:16:11.240 --> 01:16:11.620
first
01:16:11.620 --> 01:16:12.100
let's just
01:16:12.100 --> 01:16:12.420
go through
01:16:12.420 --> 01:16:12.640
this
01:16:12.640 --> 01:16:12.920
retail
01:16:12.920 --> 01:16:13.380
response
01:16:14.300 --> 01:16:14.760
as to
01:16:14.760 --> 01:16:15.140
understand
01:16:15.140 --> 01:16:15.660
what exactly
01:16:15.660 --> 01:16:16.120
the product
01:16:16.120 --> 01:16:16.460
response
01:16:16.460 --> 01:16:17.020
looks like
01:16:17.020 --> 01:16:18.000
so if you see
01:16:18.000 --> 01:16:18.740
over here
01:16:19.420 --> 01:16:20.140
it is
01:16:20.140 --> 01:16:20.500
created
01:16:20.500 --> 01:16:21.060
with the help
01:16:21.060 --> 01:16:21.860
of
01:16:21.860 --> 01:16:22.220
yaml
01:16:22.220 --> 01:16:22.800
based syntax
01:16:22.800 --> 01:16:23.280
that I have
01:16:23.280 --> 01:16:23.680
described
01:16:23.680 --> 01:16:24.020
here
01:16:24.820 --> 01:16:25.500
so
01:16:25.500 --> 01:16:26.400
inside
01:16:26.400 --> 01:16:26.740
this
01:16:26.740 --> 01:16:27.140
users
01:16:27.140 --> 01:16:27.460
key
01:16:27.460 --> 01:16:27.820
we do
01:16:27.820 --> 01:16:27.960
have
01:16:27.960 --> 01:16:28.140
different
01:16:31.180 --> 01:16:31.860
basically
01:16:31.860 --> 01:16:32.540
subkeys
01:16:32.540 --> 01:16:33.520
subkeys
01:16:33.520 --> 01:16:34.080
and
01:16:34.080 --> 01:16:34.980
this
01:16:34.980 --> 01:16:35.300
subkeys
01:16:35.300 --> 01:16:35.720
we have
01:16:36.300 --> 01:16:37.060
the values
01:16:37.060 --> 01:16:37.840
actually
01:16:37.840 --> 01:16:38.060
their
01:16:39.340 --> 01:16:40.020
corresponding
01:16:40.020 --> 01:16:40.360
values
01:16:40.360 --> 01:16:41.060
and
01:16:41.060 --> 01:16:41.440
here
01:16:41.440 --> 01:16:41.700
we are
01:16:41.700 --> 01:16:42.000
using
01:16:42.000 --> 01:16:42.720
templates
01:16:43.500 --> 01:16:44.100
in terms
01:16:44.100 --> 01:16:44.880
of raml
01:16:44.880 --> 01:16:45.520
we have
01:16:45.520 --> 01:16:45.980
lot of
01:16:45.980 --> 01:16:46.280
templates
01:16:47.040 --> 01:16:48.720
so let's say
01:16:48.720 --> 01:16:49.440
here we are
01:16:49.440 --> 01:16:49.700
using
01:16:49.700 --> 01:16:50.660
exchange modules
01:16:50.660 --> 01:16:51.320
as one of
01:16:51.320 --> 01:16:51.880
the templates
01:16:53.580 --> 01:16:54.640
so this is
01:16:54.640 --> 01:16:55.220
the file
01:16:55.220 --> 01:16:55.560
system
01:16:55.560 --> 01:16:56.100
implementation
01:16:56.820 --> 01:16:57.500
and
01:16:57.500 --> 01:16:58.520
if you go
01:16:58.520 --> 01:16:58.900
here
01:16:58.900 --> 01:16:59.920
the path
01:16:59.920 --> 01:17:00.300
will be
01:17:00.300 --> 01:17:00.660
describing
01:17:01.420 --> 01:17:01.940
will be
01:17:01.940 --> 01:17:02.180
describing
01:17:02.180 --> 01:17:02.660
a path
01:17:02.660 --> 01:17:03.100
over here
01:17:03.100 --> 01:17:03.700
the exchange
01:17:03.700 --> 01:17:04.040
modules
01:17:04.040 --> 01:17:04.440
and inside
01:17:04.440 --> 01:17:04.860
the exchange
01:17:04.860 --> 01:17:05.200
modules
01:17:05.200 --> 01:17:05.520
and
01:17:05.520 --> 01:17:05.720
whole
01:17:05.720 --> 01:17:06.020
jmule
01:17:06.020 --> 01:17:06.420
template
01:17:06.420 --> 01:17:07.600
and then
01:17:07.600 --> 01:17:08.160
we'll be
01:17:08.160 --> 01:17:08.320
going
01:17:08.320 --> 01:17:08.560
through
01:17:08.560 --> 01:17:09.060
this
01:17:09.060 --> 01:17:09.420
retail
01:17:09.420 --> 01:17:09.900
product
01:17:09.900 --> 01:17:10.940
and here
01:17:10.940 --> 01:17:11.260
the
01:17:12.120 --> 01:17:12.380
retail
01:17:12.380 --> 01:17:12.720
product
01:17:12.720 --> 01:17:12.960
of
01:17:12.960 --> 01:17:13.840
raml
01:17:13.840 --> 01:17:14.500
so we'll
01:17:14.500 --> 01:17:15.100
be describing
01:17:15.100 --> 01:17:16.340
a whole
01:17:17.020 --> 01:17:17.500
rules and
01:17:19.720 --> 01:17:20.320
implementations
01:17:21.460 --> 01:17:22.060
where
01:17:22.060 --> 01:17:22.460
or
01:17:22.460 --> 01:17:22.960
how should
01:17:22.960 --> 01:17:23.360
the request
01:17:23.360 --> 01:17:24.000
should be
01:17:24.000 --> 01:17:24.540
all those
01:17:24.540 --> 01:17:24.840
things
01:17:24.840 --> 01:17:26.180
so we are just
01:17:27.480 --> 01:17:28.080
bringing
01:17:28.080 --> 01:17:29.140
all these
01:17:29.140 --> 01:17:29.660
implementations
01:17:29.660 --> 01:17:30.040
into a
01:17:30.040 --> 01:17:30.740
separate file
01:17:30.740 --> 01:17:31.320
so that
01:17:31.320 --> 01:17:32.300
we can just
01:17:32.300 --> 01:17:32.620
bring this
01:17:33.680 --> 01:17:34.700
own file
01:17:34.700 --> 01:17:35.120
here
01:17:35.120 --> 01:17:35.400
itself
01:17:35.980 --> 01:17:36.480
funds
01:17:36.480 --> 01:17:37.180
let's say
01:17:37.180 --> 01:17:37.760
you provided
01:17:38.820 --> 01:17:39.420
url
01:17:39.420 --> 01:17:39.680
I mean
01:17:39.680 --> 01:17:40.100
the path
01:17:40.100 --> 01:17:40.760
over here
01:17:40.760 --> 01:17:41.380
everything
01:17:41.380 --> 01:17:41.740
whatever
01:17:41.740 --> 01:17:42.000
there
01:17:42.000 --> 01:17:42.460
in that
01:17:42.460 --> 01:17:42.940
specific
01:17:42.940 --> 01:17:43.860
file
01:17:43.860 --> 01:17:44.320
they will be
01:17:44.320 --> 01:17:44.740
just
01:17:44.740 --> 01:17:44.940
copy
01:17:44.940 --> 01:17:45.120
and
01:17:45.120 --> 01:17:45.480
paste it
01:17:45.480 --> 01:17:45.580
here
01:17:45.580 --> 01:17:45.940
it's like
01:17:45.940 --> 01:17:47.000
kind of
01:17:47.900 --> 01:17:48.460
modularizing
01:17:48.460 --> 01:17:48.800
things
01:17:48.800 --> 01:17:49.240
so that
01:17:49.240 --> 01:17:49.800
you can just
01:17:49.800 --> 01:17:50.340
reuse those
01:17:50.340 --> 01:17:50.700
modules
01:17:50.700 --> 01:17:51.340
or
01:17:51.340 --> 01:17:51.860
reuse those
01:17:51.860 --> 01:17:52.460
implementations
01:17:52.460 --> 01:17:53.000
wherever you
01:17:53.000 --> 01:17:53.840
want to
01:17:53.840 --> 01:17:54.340
so that's
01:17:54.340 --> 01:17:54.900
how it works
01:17:54.900 --> 01:17:55.720
so
01:17:55.720 --> 01:17:56.280
I mean
01:17:56.280 --> 01:17:58.140
you will be
01:17:58.140 --> 01:17:58.600
utilizing
01:17:58.600 --> 01:17:59.760
that specification
01:17:59.760 --> 01:18:00.380
over here
01:18:00.380 --> 01:18:00.800
but
01:18:00.800 --> 01:18:01.500
how exactly
01:18:01.500 --> 01:18:02.360
is that
01:18:02.360 --> 01:18:03.060
being designed
01:18:03.060 --> 01:18:03.880
let's just
01:18:03.880 --> 01:18:04.180
go through
01:18:04.180 --> 01:18:04.440
that
01:18:04.440 --> 01:18:04.920
so if
01:18:04.920 --> 01:18:05.340
you see
01:18:05.340 --> 01:18:05.660
over here
01:18:06.720 --> 01:18:07.420
types of
01:18:07.420 --> 01:18:07.700
products
01:18:07.700 --> 01:18:08.340
right
01:18:08.340 --> 01:18:09.000
so
01:18:09.000 --> 01:18:09.340
for
01:18:09.340 --> 01:18:09.940
retail
01:18:09.940 --> 01:18:10.500
API
01:18:11.100 --> 01:18:11.700
we have
01:18:11.700 --> 01:18:12.240
lots of
01:18:12.240 --> 01:18:12.480
products
01:18:12.480 --> 01:18:13.340
basically
01:18:14.400 --> 01:18:15.200
one of
01:18:15.200 --> 01:18:15.480
those
01:18:15.480 --> 01:18:15.720
products
01:18:15.720 --> 01:18:16.040
I mean
01:18:16.040 --> 01:18:16.540
each and
01:18:16.540 --> 01:18:17.440
there is
01:18:17.440 --> 01:18:18.040
no hard rule
01:18:18.040 --> 01:18:18.480
that
01:18:18.480 --> 01:18:18.800
each and
01:18:18.800 --> 01:18:19.240
every product
01:18:19.240 --> 01:18:19.760
has its
01:18:19.760 --> 01:18:20.440
own type
01:18:20.440 --> 01:18:21.240
as it
01:18:21.240 --> 01:18:21.720
has this
01:18:21.720 --> 01:18:22.020
should be
01:18:22.020 --> 01:18:22.380
the same
01:18:22.380 --> 01:18:23.160
same type
01:18:23.160 --> 01:18:23.460
right
01:18:23.460 --> 01:18:24.100
they might be
01:18:24.100 --> 01:18:24.360
having
01:18:24.360 --> 01:18:24.740
different
01:18:24.740 --> 01:18:25.680
types as well
01:18:25.680 --> 01:18:26.540
so
01:18:26.540 --> 01:18:27.100
that's why
01:18:27.680 --> 01:18:28.200
for
01:18:28.200 --> 01:18:28.700
type of
01:18:28.700 --> 01:18:29.120
the product
01:18:29.120 --> 01:18:30.080
we have
01:18:30.080 --> 01:18:30.720
different
01:18:30.720 --> 01:18:31.500
identifiers
01:18:31.500 --> 01:18:33.420
so let's say
01:18:33.420 --> 01:18:34.500
in
01:18:34.500 --> 01:18:34.980
I mean
01:18:34.980 --> 01:18:35.520
inside the
01:18:35.520 --> 01:18:35.740
types
01:18:36.920 --> 01:18:37.520
attribute
01:18:37.520 --> 01:18:38.480
we have
01:18:38.480 --> 01:18:39.420
the identifier
01:18:39.420 --> 01:18:40.340
the ID of
01:18:40.340 --> 01:18:40.700
the type
01:18:42.180 --> 01:18:43.260
we will be
01:18:43.260 --> 01:18:43.640
defining
01:18:43.640 --> 01:18:44.280
a type
01:18:44.280 --> 01:18:44.660
name
01:18:44.660 --> 01:18:44.860
or
01:18:45.600 --> 01:18:46.040
unique
01:18:46.040 --> 01:18:46.520
identifier
01:18:46.520 --> 01:18:47.380
for a
01:18:47.380 --> 01:18:48.360
product over here
01:18:48.360 --> 01:18:49.100
and mapping
01:18:49.100 --> 01:18:49.660
this unique
01:18:49.660 --> 01:18:50.220
identifier
01:18:50.220 --> 01:18:51.380
to a
01:18:51.380 --> 01:18:51.820
description
01:18:51.820 --> 01:18:52.840
so let's say
01:18:52.840 --> 01:18:53.180
for an
01:18:53.180 --> 01:18:53.800
example
01:18:54.700 --> 01:18:55.620
it would be
01:18:55.620 --> 01:18:56.000
very easy
01:18:56.000 --> 01:18:56.440
if we have
01:18:56.440 --> 01:18:57.000
examples actually
01:19:01.940 --> 01:19:02.500
and
01:19:02.500 --> 01:19:02.900
we have
01:19:02.900 --> 01:19:03.440
different types
01:19:04.500 --> 01:19:05.060
like
01:19:08.020 --> 01:19:08.580
food
01:19:10.780 --> 01:19:11.340
clothes
01:19:14.080 --> 01:19:14.640
medicine
01:19:14.640 --> 01:19:15.460
okay
01:19:16.280 --> 01:19:17.040
so
01:19:17.040 --> 01:19:17.580
for a
01:19:17.580 --> 01:19:17.800
layman
01:19:17.800 --> 01:19:18.180
user
01:19:18.180 --> 01:19:18.680
this is
01:19:18.680 --> 01:19:18.940
fine
01:19:18.940 --> 01:19:19.880
but for
01:19:19.880 --> 01:19:20.320
system
01:19:21.280 --> 01:19:21.800
for the
01:19:21.800 --> 01:19:22.280
application
01:19:22.280 --> 01:19:23.120
you need to
01:19:23.120 --> 01:19:24.240
have
01:19:24.800 --> 01:19:25.300
type
01:19:25.300 --> 01:19:25.820
as an
01:19:25.820 --> 01:19:26.260
attribute
01:19:26.260 --> 01:19:27.120
for a
01:19:27.120 --> 01:19:27.340
product
01:19:27.340 --> 01:19:28.360
and for
01:19:28.360 --> 01:19:29.140
this type
01:19:29.140 --> 01:19:29.700
you'll be
01:19:29.700 --> 01:19:29.900
having
01:19:29.900 --> 01:19:30.220
two
01:19:30.220 --> 01:19:30.520
different
01:19:30.520 --> 01:19:30.820
attributes
01:19:30.820 --> 01:19:31.460
like
01:19:31.460 --> 01:19:32.360
identifier
01:19:33.960 --> 01:19:35.020
which is
01:19:35.020 --> 01:19:35.460
a unique
01:19:35.460 --> 01:19:35.780
ID
01:19:35.780 --> 01:19:36.480
basically
01:19:36.480 --> 01:19:38.380
let's say
01:19:38.380 --> 01:19:39.340
D23
01:19:39.340 --> 01:19:39.800
or
01:19:42.060 --> 01:19:42.820
D2345
01:19:42.820 --> 01:19:43.600
so this is
01:19:43.600 --> 01:19:43.940
a unique
01:19:43.940 --> 01:19:44.500
identifier
01:19:44.640 --> 01:19:45.280
and
01:19:45.280 --> 01:19:45.940
this is
01:19:45.940 --> 01:19:46.220
I mean
01:19:46.220 --> 01:19:46.600
a user
01:19:46.600 --> 01:19:47.080
can't
01:19:47.080 --> 01:19:47.400
understand
01:19:47.400 --> 01:19:47.860
this
01:19:47.860 --> 01:19:48.100
specific
01:19:48.100 --> 01:19:48.240
thing
01:19:49.020 --> 01:19:49.620
so
01:19:49.620 --> 01:19:50.020
we'll
01:19:50.020 --> 01:19:50.400
be
01:19:50.400 --> 01:19:50.880
defining
01:19:51.520 --> 01:19:52.220
a
01:19:52.220 --> 01:19:52.560
description
01:19:52.560 --> 01:19:53.020
as well
01:19:53.020 --> 01:19:53.280
for that
01:19:54.820 --> 01:19:55.500
so
01:19:55.500 --> 01:19:55.720
this
01:19:55.720 --> 01:19:56.100
description
01:19:56.100 --> 01:19:56.980
provides
01:19:56.980 --> 01:19:57.400
a
01:19:57.400 --> 01:19:57.780
one-to-one
01:19:57.780 --> 01:19:58.080
mapping
01:19:58.600 --> 01:19:59.160
to a
01:19:59.160 --> 01:19:59.640
product
01:19:59.640 --> 01:20:00.340
to its
01:20:00.340 --> 01:20:00.640
type
01:20:00.640 --> 01:20:01.560
let's say
01:20:01.560 --> 01:20:02.540
D2345
01:20:02.540 --> 01:20:03.100
corresponds
01:20:03.100 --> 01:20:03.400
to a
01:20:03.400 --> 01:20:03.860
specific
01:20:03.860 --> 01:20:04.160
food
01:20:04.780 --> 01:20:05.360
product
01:20:06.080 --> 01:20:06.660
so
01:20:06.660 --> 01:20:07.480
I mean
01:20:07.480 --> 01:20:08.060
here
01:20:08.060 --> 01:20:08.560
I have
01:20:08.560 --> 01:20:09.280
provided you
01:20:09.280 --> 01:20:10.140
I mean
01:20:10.140 --> 01:20:10.620
here I have
01:20:10.620 --> 01:20:11.120
just provided
01:20:11.120 --> 01:20:11.540
description
01:20:11.540 --> 01:20:11.920
as a
01:20:11.920 --> 01:20:12.100
food
01:20:12.100 --> 01:20:12.840
but that
01:20:12.840 --> 01:20:13.100
might be
01:20:13.100 --> 01:20:13.420
anything
01:20:15.720 --> 01:20:16.460
12345
01:20:17.280 --> 01:20:17.900
but you
01:20:17.900 --> 01:20:19.360
don't want to
01:20:19.360 --> 01:20:19.720
use it
01:20:19.720 --> 01:20:20.440
to provide
01:20:20.440 --> 01:20:21.520
his own
01:20:21.520 --> 01:20:21.860
things
01:20:21.860 --> 01:20:22.160
right
01:20:22.160 --> 01:20:23.300
or his own
01:20:23.300 --> 01:20:23.800
specifications
01:20:23.800 --> 01:20:24.780
let's say
01:20:24.780 --> 01:20:25.960
hash hash hash
01:20:25.960 --> 01:20:27.000
or dollar dollar dollar
01:20:27.000 --> 01:20:28.000
or this might
01:20:28.000 --> 01:20:29.020
some kind of
01:20:29.020 --> 01:20:29.340
input
01:20:29.340 --> 01:20:30.540
can crash
01:20:30.540 --> 01:20:31.160
the system
01:20:31.160 --> 01:20:31.860
anyway
01:20:32.720 --> 01:20:33.200
so
01:20:33.200 --> 01:20:33.800
in order to
01:20:33.800 --> 01:20:34.520
restrict them
01:20:34.520 --> 01:20:35.300
so we'll be
01:20:35.300 --> 01:20:35.980
providing
01:20:36.880 --> 01:20:37.360
kind of
01:20:38.460 --> 01:20:38.880
rules
01:20:38.880 --> 01:20:39.680
for our
01:20:40.840 --> 01:20:41.260
APS
01:20:41.260 --> 01:20:41.780
specifications
01:20:41.780 --> 01:20:42.800
so those
01:20:42.800 --> 01:20:43.300
will be the
01:20:43.300 --> 01:20:43.620
patterns
01:20:43.620 --> 01:20:44.440
that we wanted to
01:20:44.440 --> 01:20:44.760
follow
01:20:44.760 --> 01:20:45.700
or minimum
01:20:45.700 --> 01:20:46.000
length
01:20:46.000 --> 01:20:46.520
or maximum
01:20:46.520 --> 01:20:47.060
length
01:20:47.060 --> 01:20:48.080
if you
01:20:48.080 --> 01:20:48.800
see
01:20:48.800 --> 01:20:49.960
a sign up forms
01:20:49.960 --> 01:20:51.360
let's say
01:20:51.360 --> 01:20:52.000
you've
01:20:52.000 --> 01:20:52.500
provided a
01:20:52.500 --> 01:20:52.960
dummy email
01:20:52.960 --> 01:20:53.560
without any
01:20:53.560 --> 01:20:53.760
entry
01:20:53.760 --> 01:20:54.040
symbol
01:20:54.040 --> 01:20:54.700
or
01:20:54.700 --> 01:20:54.940
any
01:20:54.940 --> 01:20:55.420
those things
01:20:55.420 --> 01:20:56.080
you'll be
01:20:56.080 --> 01:20:56.720
getting errors
01:20:56.720 --> 01:20:57.100
right
01:20:57.100 --> 01:20:58.060
so that's how
01:20:58.060 --> 01:20:58.540
these are
01:20:58.540 --> 01:20:58.840
controlled
01:20:58.840 --> 01:20:59.340
over here
01:20:59.340 --> 01:20:59.780
so
01:20:59.780 --> 01:21:00.320
that's how
01:21:00.320 --> 01:21:00.720
it works
01:21:01.660 --> 01:21:02.460
so it
01:21:02.460 --> 01:21:02.800
correspond
01:21:02.800 --> 01:21:03.300
the type
01:21:03.300 --> 01:21:03.740
corresponds
01:21:03.740 --> 01:21:04.020
to the
01:21:05.140 --> 01:21:05.700
identifier
01:21:05.700 --> 01:21:05.980
and
01:21:05.980 --> 01:21:06.380
identifier
01:21:06.380 --> 01:21:06.980
mapping
01:21:08.840 --> 01:21:09.400
so
01:21:09.400 --> 01:21:10.220
that is
01:21:10.220 --> 01:21:10.460
the way
01:21:10.460 --> 01:21:11.100
for example
01:21:11.880 --> 01:21:12.440
and
01:21:13.060 --> 01:21:13.460
and
01:21:13.460 --> 01:21:14.140
we have product
01:21:14.140 --> 01:21:14.680
characteristics
01:21:14.680 --> 01:21:15.100
like
01:21:15.100 --> 01:21:16.300
an object
01:21:16.300 --> 01:21:17.280
here you can see
01:21:17.280 --> 01:21:17.900
like
01:21:17.900 --> 01:21:18.540
I've told
01:21:18.540 --> 01:21:18.920
the
01:21:18.920 --> 01:21:19.380
multi-line
01:21:20.800 --> 01:21:21.480
strings
01:21:21.480 --> 01:21:22.160
basically
01:21:22.160 --> 01:21:22.660
these are
01:21:22.660 --> 01:21:23.140
multi-line
01:21:23.140 --> 01:21:23.680
strings in the
01:21:23.680 --> 01:21:24.160
sense
01:21:24.160 --> 01:21:25.280
character arrays
01:21:25.280 --> 01:21:25.740
basically
01:21:25.740 --> 01:21:26.820
and
01:21:26.820 --> 01:21:27.420
for
01:21:27.420 --> 01:21:27.740
properties
01:21:27.740 --> 01:21:28.220
we do
01:21:28.220 --> 01:21:28.440
have
01:21:28.440 --> 01:21:29.040
code as a
01:21:29.040 --> 01:21:29.420
property
01:21:29.420 --> 01:21:29.960
we do
01:21:29.960 --> 01:21:30.300
have a
01:21:30.300 --> 01:21:30.760
name as a
01:21:30.760 --> 01:21:31.140
property
01:21:31.140 --> 01:21:31.760
and
01:21:31.760 --> 01:21:32.080
description
01:21:32.080 --> 01:21:32.440
as a
01:21:32.440 --> 01:21:32.920
property
01:21:32.920 --> 01:21:33.740
so for
01:21:33.740 --> 01:21:34.060
product
01:21:34.060 --> 01:21:34.620
characteristics
01:21:34.620 --> 01:21:36.380
so let's say
01:21:37.060 --> 01:21:37.620
I'm just
01:21:37.620 --> 01:21:38.080
translating
01:21:38.080 --> 01:21:38.740
this
01:21:38.740 --> 01:21:39.120
APS
01:21:39.120 --> 01:21:39.680
specification
01:21:39.680 --> 01:21:40.460
to
01:21:40.460 --> 01:21:41.240
our user
01:21:41.860 --> 01:21:42.360
friendly
01:21:42.360 --> 01:21:42.860
scenarios
01:21:42.860 --> 01:21:43.620
to
01:21:43.620 --> 01:21:44.220
understand things
01:21:46.860 --> 01:21:48.280
so let's say
01:21:48.280 --> 01:21:49.340
each and every
01:21:49.340 --> 01:21:50.380
so
01:21:50.380 --> 01:21:51.940
this is
01:21:51.940 --> 01:21:52.400
type is
01:21:52.400 --> 01:21:53.160
specific to
01:21:53.820 --> 01:21:54.200
and
01:21:54.200 --> 01:21:54.700
again
01:21:54.700 --> 01:21:55.240
this is like
01:21:55.240 --> 01:21:55.620
business
01:21:55.620 --> 01:21:56.320
in space
01:21:56.320 --> 01:21:56.680
I mean
01:21:56.680 --> 01:21:57.260
business specific
01:21:57.260 --> 01:21:57.960
implementation
01:21:57.960 --> 01:21:58.680
right now
01:21:58.680 --> 01:21:59.280
we have taken
01:21:59.280 --> 01:21:59.860
example of
01:21:59.860 --> 01:22:00.280
a product
01:22:00.280 --> 01:22:00.680
catalog
01:22:00.680 --> 01:22:01.700
that might be
01:22:01.700 --> 01:22:02.200
anything
01:22:02.200 --> 01:22:02.680
specific to
01:22:02.680 --> 01:22:03.260
the project
01:22:03.820 --> 01:22:04.460
okay
01:22:04.460 --> 01:22:05.180
so the product
01:22:05.180 --> 01:22:05.660
characteristics
01:22:05.660 --> 01:22:06.240
comes in
01:22:06.240 --> 01:22:06.600
comes with
01:22:06.600 --> 01:22:07.140
different
01:22:07.140 --> 01:22:07.640
attributes
01:22:07.640 --> 01:22:08.520
like
01:22:08.520 --> 01:22:09.000
the code
01:22:09.000 --> 01:22:09.540
attribute
01:22:09.540 --> 01:22:10.700
and then
01:22:10.700 --> 01:22:11.160
name
01:22:11.160 --> 01:22:11.720
attribute
01:22:12.380 --> 01:22:13.340
and then
01:22:13.340 --> 01:22:13.960
a description
01:22:14.620 --> 01:22:15.220
attribute
01:22:20.520 --> 01:22:21.600
so we can just
01:22:21.600 --> 01:22:22.340
provide all these
01:22:22.340 --> 01:22:22.920
details over
01:22:22.920 --> 01:22:23.160
here
01:22:23.160 --> 01:22:24.080
and I think
01:22:24.080 --> 01:22:25.060
that
01:22:25.060 --> 01:22:25.780
subsequent
01:22:25.780 --> 01:22:26.720
these are
01:22:26.720 --> 01:22:27.080
the same
01:22:27.860 --> 01:22:28.540
things like
01:22:28.540 --> 01:22:29.060
we will be
01:22:29.060 --> 01:22:29.500
configuring
01:22:29.500 --> 01:22:29.880
each and
01:22:29.880 --> 01:22:30.220
everything
01:22:30.220 --> 01:22:31.600
but one of the
01:22:31.600 --> 01:22:32.260
most important
01:22:32.260 --> 01:22:32.600
thing
01:22:32.600 --> 01:22:33.160
over here is
01:22:34.400 --> 01:22:34.680
the
01:22:34.680 --> 01:22:35.140
syntaxes
01:22:35.140 --> 01:22:35.500
that we
01:22:35.500 --> 01:22:35.720
follow
01:22:35.720 --> 01:22:36.320
you have to
01:22:36.320 --> 01:22:36.860
understand
01:22:36.860 --> 01:22:37.680
how exactly
01:22:37.680 --> 01:22:37.940
the
01:22:37.940 --> 01:22:38.460
syntaxes
01:22:38.460 --> 01:22:38.620
are
01:22:38.620 --> 01:22:38.960
working
01:22:38.960 --> 01:22:40.220
so let's say
01:22:40.220 --> 01:22:40.700
here
01:22:40.700 --> 01:22:41.400
if you see
01:22:41.400 --> 01:22:41.700
right
01:22:41.720 --> 01:22:42.540
this product
01:22:42.540 --> 01:22:43.560
characteristic
01:22:43.560 --> 01:22:43.880
characteristic
01:22:43.880 --> 01:22:44.220
value
01:22:44.220 --> 01:22:44.680
is a
01:22:44.680 --> 01:22:45.220
type of
01:22:45.220 --> 01:22:45.760
object
01:22:45.760 --> 01:22:46.860
what exactly
01:22:46.860 --> 01:22:47.380
is this object
01:22:47.380 --> 01:22:48.140
basically
01:22:49.040 --> 01:22:50.080
if you see
01:22:50.080 --> 01:22:50.520
over here
01:22:51.220 --> 01:22:52.120
this identifier
01:22:52.120 --> 01:22:52.560
is a kind
01:22:52.560 --> 01:22:52.940
of type
01:22:52.940 --> 01:22:53.500
of string
01:22:53.500 --> 01:22:54.520
so you
01:22:54.520 --> 01:22:54.920
have only
01:22:56.140 --> 01:22:57.320
a single
01:22:57.320 --> 01:22:57.680
key
01:22:57.680 --> 01:22:58.380
and
01:22:58.380 --> 01:22:59.280
the corresponding
01:22:59.280 --> 01:22:59.540
value
01:22:59.540 --> 01:23:00.060
that's all
01:23:00.060 --> 01:23:00.880
but if you
01:23:00.880 --> 01:23:01.340
see over
01:23:01.340 --> 01:23:02.020
here
01:23:02.020 --> 01:23:02.500
identifier
01:23:02.500 --> 01:23:02.920
map
01:23:02.920 --> 01:23:03.520
is an
01:23:03.520 --> 01:23:03.960
object
01:23:03.960 --> 01:23:04.700
it has
01:23:04.700 --> 01:23:05.000
two
01:23:05.000 --> 01:23:05.880
different
01:23:05.880 --> 01:23:06.240
keys
01:23:06.240 --> 01:23:06.860
and
01:23:06.860 --> 01:23:07.140
the
01:23:07.140 --> 01:23:07.500
corresponding
01:23:07.500 --> 01:23:08.080
values
01:23:08.080 --> 01:23:09.060
like
01:23:09.060 --> 01:23:09.680
description
01:23:09.680 --> 01:23:10.000
is a
01:23:10.000 --> 01:23:10.200
key
01:23:10.200 --> 01:23:10.900
and then
01:23:10.900 --> 01:23:11.220
properties
01:23:11.220 --> 01:23:11.580
is a
01:23:11.580 --> 01:23:11.700
key
01:23:13.220 --> 01:23:14.500
and then
01:23:14.500 --> 01:23:15.040
product
01:23:15.040 --> 01:23:15.840
characteristic
01:23:15.840 --> 01:23:16.540
is also
01:23:16.540 --> 01:23:16.940
kind of
01:23:16.940 --> 01:23:17.380
type of
01:23:17.380 --> 01:23:17.620
object
01:23:17.620 --> 01:23:18.960
it has
01:23:18.960 --> 01:23:19.400
description
01:23:19.400 --> 01:23:19.960
over here
01:23:19.960 --> 01:23:20.700
and properties
01:23:20.700 --> 01:23:21.440
over here
01:23:21.440 --> 01:23:22.100
and properties
01:23:22.100 --> 01:23:22.280
has
01:23:23.380 --> 01:23:24.020
inner
01:23:24.020 --> 01:23:24.600
characteristics
01:23:24.600 --> 01:23:25.040
as well
01:23:25.040 --> 01:23:25.840
like code
01:23:25.840 --> 01:23:26.780
and it is
01:23:26.780 --> 01:23:27.640
a type of string
01:23:27.640 --> 01:23:28.620
this type
01:23:28.620 --> 01:23:29.000
itself
01:23:29.000 --> 01:23:29.540
is like
01:23:29.540 --> 01:23:29.800
built in
01:23:32.140 --> 01:23:32.780
thing
01:23:32.780 --> 01:23:33.080
for
01:23:33.080 --> 01:23:33.480
raml
01:23:33.480 --> 01:23:34.240
specification
01:23:34.920 --> 01:23:35.580
if you wanted
01:23:35.580 --> 01:23:36.120
to learn
01:23:36.120 --> 01:23:36.440
more
01:23:36.440 --> 01:23:36.600
about
01:23:37.500 --> 01:23:38.180
a raml
01:23:38.180 --> 01:23:38.600
and how
01:23:38.600 --> 01:23:38.940
what is
01:23:38.940 --> 01:23:39.480
the syntax
01:23:39.480 --> 01:23:40.260
of raml
01:23:41.220 --> 01:23:41.940
I would
01:23:41.940 --> 01:23:42.520
suggest
01:23:42.520 --> 01:23:43.100
to go
01:23:43.100 --> 01:23:43.560
through
01:23:43.560 --> 01:23:44.440
this
01:23:44.440 --> 01:23:45.060
documentation
01:23:47.220 --> 01:23:47.600
to
01:23:47.600 --> 01:23:47.860
have
01:23:49.060 --> 01:23:49.600
the
01:23:49.600 --> 01:23:50.080
detailed
01:23:50.080 --> 01:23:50.620
implementation
01:23:50.620 --> 01:23:51.380
aspects
01:23:53.200 --> 01:23:54.120
so
01:23:54.120 --> 01:23:55.600
this is
01:23:55.600 --> 01:23:55.720
how
01:23:55.720 --> 01:23:56.320
how a raml
01:23:56.320 --> 01:23:56.580
works
01:23:56.580 --> 01:23:57.180
basically
01:23:57.180 --> 01:23:58.020
we can
01:23:58.020 --> 01:23:58.360
just
01:23:58.360 --> 01:23:58.720
go through
01:23:58.720 --> 01:23:58.920
this
01:23:58.920 --> 01:23:59.500
documentation
01:24:00.180 --> 01:24:00.740
I'll be
01:24:00.740 --> 01:24:00.940
sharing
01:24:00.940 --> 01:24:01.240
these
01:24:01.240 --> 01:24:01.580
links
01:24:01.580 --> 01:24:02.480
later
01:24:02.480 --> 01:24:03.240
once you're
01:24:03.240 --> 01:24:03.380
done
01:24:03.380 --> 01:24:04.140
with it
01:24:07.460 --> 01:24:07.780
so
01:24:07.780 --> 01:24:08.260
that's
01:24:08.260 --> 01:24:08.560
how
01:24:08.560 --> 01:24:09.020
it works
01:24:09.020 --> 01:24:09.460
basically
01:24:09.460 --> 01:24:10.240
and
01:24:10.240 --> 01:24:10.780
then
01:24:10.780 --> 01:24:11.200
yeah
01:24:12.100 --> 01:24:12.860
so
01:24:12.860 --> 01:24:14.020
this is
01:24:15.400 --> 01:24:16.160
specification
01:24:16.160 --> 01:24:17.200
how should
01:24:17.200 --> 01:24:17.700
how
01:24:17.700 --> 01:24:18.000
an item
01:24:18.000 --> 01:24:18.580
should be
01:24:18.580 --> 01:24:19.420
so
01:24:19.420 --> 01:24:19.760
let's say
01:24:20.300 --> 01:24:21.480
there are
01:24:21.480 --> 01:24:21.840
nested
01:24:21.840 --> 01:24:22.340
syntaxes
01:24:22.340 --> 01:24:22.760
or
01:24:22.760 --> 01:24:23.240
nested
01:24:23.240 --> 01:24:23.840
specifications
01:24:23.840 --> 01:24:24.580
where
01:24:24.580 --> 01:24:25.420
a product
01:24:25.420 --> 01:24:26.000
depends upon
01:24:27.340 --> 01:24:27.920
another
01:24:28.560 --> 01:24:29.160
attribute
01:24:29.160 --> 01:24:29.780
of the product
01:24:29.780 --> 01:24:30.060
itself
01:24:30.060 --> 01:24:30.540
like
01:24:30.540 --> 01:24:30.960
that we have
01:24:30.960 --> 01:24:31.280
defined
01:24:31.280 --> 01:24:31.660
like
01:24:31.660 --> 01:24:32.340
identify
01:24:32.340 --> 01:24:33.120
that we have defined
01:24:33.120 --> 01:24:33.700
so
01:24:33.700 --> 01:24:34.480
here in that
01:24:34.480 --> 01:24:34.960
scenarios
01:24:34.960 --> 01:24:35.740
we'll be using
01:24:35.740 --> 01:24:36.400
dot syntax
01:24:36.400 --> 01:24:37.240
basically
01:24:37.240 --> 01:24:37.780
common
01:24:37.780 --> 01:24:38.560
dot
01:24:38.560 --> 01:24:39.260
resource ID
01:24:40.060 --> 01:24:40.380
so
01:24:40.380 --> 01:24:40.980
basically
01:24:42.640 --> 01:24:43.540
we have
01:24:43.540 --> 01:24:44.080
already
01:24:44.080 --> 01:24:44.720
defined
01:24:45.540 --> 01:24:46.220
this
01:24:46.220 --> 01:24:46.940
resource ID
01:24:46.940 --> 01:24:47.440
over here
01:24:47.440 --> 01:24:48.260
and we'll be
01:24:48.260 --> 01:24:48.580
utilizing
01:24:48.580 --> 01:24:49.260
this resource ID
01:24:49.840 --> 01:24:50.400
down
01:24:50.400 --> 01:24:51.100
there
01:24:51.100 --> 01:24:52.000
so
01:24:52.000 --> 01:24:52.480
for product
01:24:52.480 --> 01:24:52.780
variant
01:24:52.780 --> 01:24:53.480
we'll be using
01:24:53.480 --> 01:24:53.920
I mean
01:24:53.920 --> 01:24:54.340
we'll be
01:24:54.340 --> 01:24:54.960
mapping
01:24:54.960 --> 01:24:55.800
a one
01:24:55.800 --> 01:24:56.060
attribute
01:24:56.060 --> 01:24:56.460
which is
01:24:56.460 --> 01:24:56.660
already
01:24:56.660 --> 01:24:57.260
present
01:24:57.260 --> 01:24:58.180
to
01:24:58.180 --> 01:24:58.860
the other
01:24:58.860 --> 01:24:59.280
attribute
01:24:59.900 --> 01:25:00.280
so
01:25:00.280 --> 01:25:00.840
let's say
01:25:00.840 --> 01:25:01.200
I mean
01:25:01.200 --> 01:25:01.940
to understand
01:25:01.940 --> 01:25:03.220
help you
01:25:03.220 --> 01:25:03.580
understand
01:25:03.580 --> 01:25:03.980
more
01:25:03.980 --> 01:25:04.540
efficiently
01:25:04.540 --> 01:25:05.320
so
01:25:05.320 --> 01:25:05.880
let's say
01:25:05.880 --> 01:25:06.460
you have
01:25:07.140 --> 01:25:07.700
a scenario
01:25:07.700 --> 01:25:08.500
like this
01:25:08.500 --> 01:25:09.140
like
01:25:09.140 --> 01:25:09.980
for food
01:25:09.980 --> 01:25:10.840
you have
01:25:10.840 --> 01:25:11.440
a type
01:25:11.440 --> 01:25:12.000
identifier
01:25:12.000 --> 01:25:12.100
of
01:25:14.500 --> 01:25:15.620
chocolate
01:25:18.580 --> 01:25:19.180
and
01:25:19.180 --> 01:25:19.540
description
01:25:21.180 --> 01:25:22.300
is
01:25:22.300 --> 01:25:22.980
sample
01:25:25.700 --> 01:25:25.880
code
01:25:28.740 --> 01:25:29.240
and
01:25:29.240 --> 01:25:29.700
name
01:25:29.700 --> 01:25:30.860
should be
01:25:31.700 --> 01:25:32.200
in your
01:25:32.200 --> 01:25:32.760
organization
01:25:32.760 --> 01:25:33.820
you have
01:25:33.820 --> 01:25:34.420
a specific
01:25:37.140 --> 01:25:37.540
rule
01:25:37.540 --> 01:25:38.060
that
01:25:38.620 --> 01:25:39.880
each and every
01:25:39.880 --> 01:25:40.420
product name
01:25:40.420 --> 01:25:40.900
should
01:25:40.900 --> 01:25:41.440
have
01:25:41.440 --> 01:25:41.680
appended
01:25:41.680 --> 01:25:42.460
with the
01:25:42.460 --> 01:25:43.480
identifier unique
01:25:43.480 --> 01:25:43.840
identifier
01:25:43.840 --> 01:25:44.420
with that
01:25:44.420 --> 01:25:44.900
so
01:25:44.900 --> 01:25:45.200
you have
01:25:45.200 --> 01:25:45.420
to
01:25:45.420 --> 01:25:45.740
enforce
01:25:45.740 --> 01:25:46.280
that
01:25:46.280 --> 01:25:46.820
so
01:25:46.820 --> 01:25:47.300
let's say
01:25:47.300 --> 01:25:47.700
in those
01:25:47.700 --> 01:25:48.280
scenarios
01:25:48.860 --> 01:25:49.440
let's say
01:25:49.440 --> 01:25:49.860
for this
01:25:49.860 --> 01:25:50.120
specific
01:25:50.120 --> 01:25:50.640
use case
01:25:50.640 --> 01:25:51.320
what you'll do
01:25:51.320 --> 01:25:51.760
is
01:25:51.760 --> 01:25:52.740
just say
01:25:52.740 --> 01:25:52.940
a
01:25:52.940 --> 01:25:53.220
category
01:25:54.240 --> 01:25:55.520
and then
01:25:57.680 --> 01:25:58.460
you'll be
01:25:58.460 --> 01:25:58.740
just
01:25:58.740 --> 01:25:59.480
appending
01:25:59.480 --> 01:25:59.960
type
01:25:59.960 --> 01:26:00.140
dot
01:26:01.020 --> 01:26:01.660
identifier
01:26:02.900 --> 01:26:03.540
yeah
01:26:03.540 --> 01:26:04.080
so
01:26:04.080 --> 01:26:05.020
that's how
01:26:05.020 --> 01:26:05.960
you'll be
01:26:05.960 --> 01:26:06.180
using
01:26:06.180 --> 01:26:06.600
nested
01:26:06.600 --> 01:26:07.320
syntaxes
01:26:07.320 --> 01:26:07.600
with the
01:26:07.600 --> 01:26:08.040
help of
01:26:08.040 --> 01:26:08.760
dot syntax
01:26:08.760 --> 01:26:09.760
so this
01:26:09.760 --> 01:26:10.180
dot syntax
01:26:10.180 --> 01:26:11.180
is being used
01:26:11.180 --> 01:26:12.040
like these
01:26:12.040 --> 01:26:12.560
scenarios
01:26:12.560 --> 01:26:13.080
where you
01:26:13.080 --> 01:26:13.620
wanted to
01:26:13.620 --> 01:26:14.040
reuse
01:26:14.880 --> 01:26:15.500
the attributes
01:26:15.500 --> 01:26:15.840
that are
01:26:15.840 --> 01:26:16.060
already
01:26:16.060 --> 01:26:16.460
present
01:26:16.460 --> 01:26:17.100
so that
01:26:17.100 --> 01:26:17.380
you can
01:26:17.380 --> 01:26:17.980
maintain
01:26:17.980 --> 01:26:18.660
so
01:26:18.660 --> 01:26:19.220
the first
01:26:19.220 --> 01:26:19.840
and foremost
01:26:19.840 --> 01:26:20.460
advantage
01:26:20.460 --> 01:26:20.880
here is
01:26:21.640 --> 01:26:22.200
you'll be
01:26:22.200 --> 01:26:22.560
maintaining
01:26:22.560 --> 01:26:23.240
a single
01:26:23.240 --> 01:26:23.600
thing
01:26:23.600 --> 01:26:24.060
and a
01:26:24.060 --> 01:26:24.180
single
01:26:24.180 --> 01:26:24.600
place
01:26:25.360 --> 01:26:25.960
so the
01:26:25.960 --> 01:26:26.200
maintenance
01:26:26.200 --> 01:26:26.640
become
01:26:26.640 --> 01:26:27.180
very
01:26:27.180 --> 01:26:27.480
easy
01:26:27.480 --> 01:26:28.040
over here
01:26:28.040 --> 01:26:28.820
and there
01:26:28.820 --> 01:26:28.880
is
01:26:30.320 --> 01:26:30.960
like
01:26:30.960 --> 01:26:31.440
if you
01:26:31.440 --> 01:26:31.760
duplicate
01:26:31.760 --> 01:26:32.240
things
01:26:32.240 --> 01:26:32.860
then
01:26:32.860 --> 01:26:33.260
let's say
01:26:33.260 --> 01:26:33.860
you wanted to
01:26:33.860 --> 01:26:34.000
change
01:26:35.000 --> 01:26:35.640
identifier
01:26:35.640 --> 01:26:36.220
in later
01:26:36.220 --> 01:26:36.700
point of
01:26:36.700 --> 01:26:37.020
time
01:26:37.020 --> 01:26:37.580
and
01:26:37.580 --> 01:26:38.260
you have
01:26:38.260 --> 01:26:39.080
to trouble
01:26:39.080 --> 01:26:39.800
like
01:26:39.800 --> 01:26:40.060
hiding
01:26:40.060 --> 01:26:40.460
making
01:26:40.460 --> 01:26:40.960
modifying
01:26:40.960 --> 01:26:41.240
them
01:26:41.240 --> 01:26:41.640
each and
01:26:41.640 --> 01:26:42.180
everywhere
01:26:43.460 --> 01:26:44.460
so that is
01:26:44.460 --> 01:26:44.760
like
01:26:44.760 --> 01:26:45.020
very
01:26:45.020 --> 01:26:45.500
painsome
01:26:45.500 --> 01:26:46.260
so this
01:26:46.260 --> 01:26:46.640
is like
01:26:46.640 --> 01:26:46.780
not
01:26:49.680 --> 01:26:50.260
implemented
01:26:50.260 --> 01:26:50.860
or
01:26:50.860 --> 01:26:51.380
distributed
01:26:51.380 --> 01:26:52.420
or
01:26:52.420 --> 01:26:52.940
like
01:26:52.940 --> 01:26:53.340
compensated
01:26:53.340 --> 01:26:53.700
anywhere
01:26:53.700 --> 01:26:54.300
this is like
01:26:54.300 --> 01:26:54.800
best practice
01:26:54.800 --> 01:26:55.600
you can say
01:26:55.600 --> 01:26:56.220
with the
01:26:56.220 --> 01:26:56.860
help of
01:26:56.860 --> 01:26:57.260
like
01:26:57.260 --> 01:26:57.720
while
01:26:57.720 --> 01:26:58.160
developing
01:26:58.160 --> 01:26:58.700
the APIs
01:26:58.700 --> 01:26:59.700
so that
01:26:59.700 --> 01:27:00.280
is
01:27:00.280 --> 01:27:00.520
the first
01:27:00.520 --> 01:27:00.800
thing
01:27:00.800 --> 01:27:01.340
and
01:27:01.340 --> 01:27:01.820
when it
01:27:01.820 --> 01:27:02.140
comes to
01:27:04.020 --> 01:27:04.600
yeah
01:27:04.600 --> 01:27:05.540
if you see
01:27:05.540 --> 01:27:05.780
the
01:27:05.780 --> 01:27:06.200
question mark
01:27:06.200 --> 01:27:06.540
syntax
01:27:06.540 --> 01:27:07.180
over here
01:27:07.180 --> 01:27:08.140
this question mark
01:27:08.140 --> 01:27:08.560
syntax
01:27:08.560 --> 01:27:08.940
basically
01:27:11.100 --> 01:27:12.380
provides us
01:27:12.380 --> 01:27:13.020
a description
01:27:13.020 --> 01:27:14.700
that this is
01:27:15.420 --> 01:27:16.060
a kind of
01:27:17.760 --> 01:27:18.400
optional
01:27:18.400 --> 01:27:19.340
parameter
01:27:19.340 --> 01:27:20.220
basically
01:27:20.220 --> 01:27:21.360
so let's say
01:27:21.360 --> 01:27:22.320
first you wanted to
01:27:22.320 --> 01:27:22.520
have
01:27:22.520 --> 01:27:22.920
I mean
01:27:22.920 --> 01:27:23.300
populate
01:27:23.300 --> 01:27:24.820
all the
01:27:24.820 --> 01:27:25.520
attributes
01:27:26.300 --> 01:27:26.880
you can
01:27:26.880 --> 01:27:27.200
I mean
01:27:27.200 --> 01:27:28.420
you are
01:27:29.420 --> 01:27:30.060
comfortable
01:27:30.060 --> 01:27:30.480
enough
01:27:30.480 --> 01:27:31.060
to skip
01:27:31.060 --> 01:27:31.720
few of the
01:27:31.720 --> 01:27:32.020
attributes
01:27:32.020 --> 01:27:32.700
so in that
01:27:32.700 --> 01:27:32.940
scenario
01:27:32.940 --> 01:27:33.280
you will be
01:27:33.280 --> 01:27:33.760
just
01:27:33.760 --> 01:27:34.540
providing
01:27:35.260 --> 01:27:35.260
these
01:27:36.520 --> 01:27:37.200
optional
01:27:37.200 --> 01:27:37.600
attributes
01:27:37.600 --> 01:27:38.480
basically
01:27:38.480 --> 01:27:39.180
question mark
01:27:39.180 --> 01:27:39.700
syntax
01:27:39.700 --> 01:27:40.360
comes for
01:27:40.360 --> 01:27:41.200
that basically
01:27:41.200 --> 01:27:42.720
so that's how
01:27:42.720 --> 01:27:43.340
the whole
01:27:43.340 --> 01:27:43.980
syntaxes
01:27:43.980 --> 01:27:44.660
work here
01:27:44.660 --> 01:27:45.480
and
01:27:45.480 --> 01:27:45.920
again
01:27:45.920 --> 01:27:46.440
when it
01:27:46.440 --> 01:27:46.700
comes to
01:27:47.780 --> 01:27:48.480
the actual
01:27:48.480 --> 01:27:49.040
root file
01:27:49.040 --> 01:27:49.760
you will be
01:27:49.760 --> 01:27:50.340
just importing
01:27:50.340 --> 01:27:51.040
the file
01:27:51.040 --> 01:27:51.940
the API
01:27:51.940 --> 01:27:52.520
specification
01:27:52.520 --> 01:27:52.800
file
01:27:52.800 --> 01:27:53.320
that we have
01:27:53.320 --> 01:27:53.660
discussed
01:27:53.660 --> 01:27:54.440
till now
01:27:54.440 --> 01:27:55.060
into the
01:27:55.060 --> 01:27:55.280
root
01:27:55.280 --> 01:27:55.960
specification
01:27:56.900 --> 01:27:57.960
and then
01:27:57.960 --> 01:27:58.520
here
01:27:58.520 --> 01:27:59.100
we'll be
01:27:59.100 --> 01:27:59.340
providing
01:27:59.340 --> 01:28:00.100
the responses
01:28:00.100 --> 01:28:00.860
basically
01:28:01.660 --> 01:28:02.360
how this
01:28:02.360 --> 01:28:02.680
response
01:28:02.680 --> 01:28:03.000
works
01:28:03.000 --> 01:28:03.760
basically
01:28:03.760 --> 01:28:04.500
we'll be
01:28:04.500 --> 01:28:04.980
describing
01:28:06.080 --> 01:28:07.100
a product
01:28:07.100 --> 01:28:07.580
response
01:28:07.580 --> 01:28:10.040
as one of the
01:28:10.040 --> 01:28:10.880
response
01:28:10.880 --> 01:28:11.400
implementation
01:28:11.400 --> 01:28:12.300
and you'll be
01:28:12.300 --> 01:28:12.540
using
01:28:13.660 --> 01:28:14.200
I mean
01:28:14.200 --> 01:28:14.700
you just
01:28:14.700 --> 01:28:14.980
using
01:28:14.980 --> 01:28:15.940
this product
01:28:15.940 --> 01:28:16.420
product
01:28:16.420 --> 01:28:16.820
response
01:28:16.820 --> 01:28:17.820
so let's say
01:28:17.820 --> 01:28:18.180
we have
01:28:18.180 --> 01:28:18.800
already
01:28:18.800 --> 01:28:19.440
discussed
01:28:24.140 --> 01:28:24.920
yeah
01:28:28.200 --> 01:28:29.200
the response
01:28:29.200 --> 01:28:29.700
characteristic
01:28:29.700 --> 01:28:30.680
so the
01:28:30.680 --> 01:28:31.240
response
01:28:31.240 --> 01:28:31.600
works
01:28:31.600 --> 01:28:32.480
like this
01:28:32.480 --> 01:28:33.060
so what
01:28:33.060 --> 01:28:34.140
will be
01:28:34.140 --> 01:28:34.640
just
01:28:34.640 --> 01:28:35.420
if you
01:28:35.580 --> 01:28:36.100
do
01:28:37.080 --> 01:28:38.560
if you see
01:28:38.560 --> 01:28:39.100
over here
01:28:39.100 --> 01:28:39.680
you are
01:28:39.680 --> 01:28:39.940
using
01:28:39.940 --> 01:28:40.380
capital
01:28:40.380 --> 01:28:40.980
P
01:28:40.980 --> 01:28:41.100
and
01:28:42.140 --> 01:28:42.360
of
01:28:42.360 --> 01:28:42.800
fetching
01:28:42.800 --> 01:28:43.340
whatever
01:28:43.340 --> 01:28:44.120
that is
01:28:44.120 --> 01:28:44.280
there
01:28:44.280 --> 01:28:44.600
inside
01:28:45.320 --> 01:28:45.920
this
01:28:45.920 --> 01:28:46.340
path
01:28:46.340 --> 01:28:47.060
if you
01:28:47.060 --> 01:28:47.460
see over
01:28:47.460 --> 01:28:47.740
here
01:28:47.740 --> 01:28:48.340
in this
01:28:48.340 --> 01:28:48.600
path
01:28:48.600 --> 01:28:49.400
the
01:28:49.400 --> 01:28:49.760
pattern
01:28:49.760 --> 01:28:50.120
of
01:28:50.120 --> 01:28:50.720
the response
01:28:50.720 --> 01:28:51.120
should be
01:28:51.120 --> 01:28:51.340
like this
01:28:52.320 --> 01:28:52.920
so
01:28:52.920 --> 01:28:53.460
yeah
01:28:53.460 --> 01:28:53.960
we'll be
01:28:53.960 --> 01:28:54.200
defining
01:28:54.200 --> 01:28:54.660
each and
01:28:54.660 --> 01:28:54.880
every
01:28:54.880 --> 01:28:55.500
property
01:28:55.500 --> 01:28:56.260
on top
01:28:56.260 --> 01:28:57.100
and just
01:28:57.100 --> 01:28:57.600
utilizing
01:28:57.600 --> 01:28:58.560
already
01:28:58.560 --> 01:28:58.980
defined
01:28:58.980 --> 01:28:59.620
properties
01:28:59.620 --> 01:29:00.380
here in
01:29:00.380 --> 01:29:00.840
the bottom
01:29:00.840 --> 01:29:01.240
like for
01:29:01.240 --> 01:29:01.700
description
01:29:01.700 --> 01:29:02.480
we have
01:29:02.480 --> 01:29:02.940
validated
01:29:02.940 --> 01:29:03.460
what
01:29:03.460 --> 01:29:03.980
a description
01:29:03.980 --> 01:29:04.360
should be
01:29:04.360 --> 01:29:04.640
like
01:29:05.580 --> 01:29:06.320
description should
01:29:06.320 --> 01:29:06.600
be like
01:29:06.600 --> 01:29:07.220
what is the
01:29:07.220 --> 01:29:07.540
minimum length
01:29:07.540 --> 01:29:08.080
of the
01:29:08.080 --> 01:29:08.780
description should
01:29:08.780 --> 01:29:09.160
be like
01:29:09.160 --> 01:29:10.380
and we'll just
01:29:10.380 --> 01:29:10.940
describe
01:29:10.940 --> 01:29:11.380
a product
01:29:11.380 --> 01:29:11.840
should have
01:29:11.840 --> 01:29:12.200
description
01:29:12.200 --> 01:29:12.860
that's all
01:29:12.860 --> 01:29:13.640
we'll not
01:29:13.640 --> 01:29:14.140
describe
01:29:14.140 --> 01:29:15.060
over here
01:29:15.060 --> 01:29:15.520
how a
01:29:15.520 --> 01:29:16.420
description should be
01:29:16.420 --> 01:29:17.140
so you've
01:29:17.140 --> 01:29:17.640
got right
01:29:18.300 --> 01:29:19.040
so basically
01:29:19.040 --> 01:29:19.660
we'll be building
01:29:19.660 --> 01:29:20.680
step by step
01:29:20.680 --> 01:29:21.580
first we'll be
01:29:21.580 --> 01:29:22.020
describing
01:29:22.020 --> 01:29:22.860
a description
01:29:22.860 --> 01:29:23.660
and then
01:29:24.620 --> 01:29:25.400
each and
01:29:26.000 --> 01:29:26.560
every
01:29:26.560 --> 01:29:27.280
components
01:29:27.280 --> 01:29:28.020
that is
01:29:28.020 --> 01:29:28.500
that should be
01:29:28.500 --> 01:29:28.880
present inside
01:29:28.880 --> 01:29:29.280
a product
01:29:29.280 --> 01:29:29.960
and then
01:29:29.960 --> 01:29:30.360
we'll be
01:29:30.360 --> 01:29:30.820
framing a
01:29:30.820 --> 01:29:31.280
product over
01:29:31.280 --> 01:29:31.600
here
01:29:31.600 --> 01:29:32.320
and then
01:29:32.320 --> 01:29:32.700
we'll be
01:29:32.700 --> 01:29:33.040
using
01:29:33.040 --> 01:29:33.580
a product
01:29:33.580 --> 01:29:34.140
inside the
01:29:34.140 --> 01:29:34.880
response itself
01:29:34.880 --> 01:29:35.500
product
01:29:35.500 --> 01:29:35.940
response
01:29:36.720 --> 01:29:37.960
so that's
01:29:37.960 --> 01:29:39.320
how
01:29:39.320 --> 01:29:40.140
APA
01:29:40.140 --> 01:29:40.640
specification
01:29:40.640 --> 01:29:41.100
should be
01:29:41.100 --> 01:29:41.260
built
01:29:41.260 --> 01:29:41.640
for
01:29:41.640 --> 01:29:42.520
raml
01:29:42.520 --> 01:29:43.020
language
01:29:43.020 --> 01:29:43.660
and
01:29:43.660 --> 01:29:44.080
similarly
01:29:44.080 --> 01:29:44.560
we have
01:29:44.560 --> 01:29:45.240
product
01:29:45.240 --> 01:29:45.680
collection
01:29:45.680 --> 01:29:46.360
response
01:29:46.360 --> 01:29:46.880
and product
01:29:46.880 --> 01:29:47.200
variant
01:29:47.200 --> 01:29:47.540
collection
01:29:47.540 --> 01:29:48.060
response
01:29:48.060 --> 01:29:48.920
and all
01:29:48.920 --> 01:29:49.340
so
01:29:49.340 --> 01:29:49.720
these are
01:29:49.720 --> 01:29:50.200
like
01:29:50.800 --> 01:29:51.200
if you
01:29:51.720 --> 01:29:52.780
we can
01:29:52.780 --> 01:29:53.240
just go
01:29:53.240 --> 01:29:53.580
through
01:29:53.580 --> 01:29:53.840
over here
01:29:54.720 --> 01:29:55.740
we can
01:29:55.740 --> 01:29:56.000
have
01:29:56.000 --> 01:29:56.220
I mean
01:29:56.220 --> 01:29:56.700
if we have
01:29:56.700 --> 01:29:57.240
some time
01:29:57.240 --> 01:29:58.180
but just
01:29:58.180 --> 01:29:59.120
like mostly
01:29:59.120 --> 01:29:59.600
similarly
01:29:59.600 --> 01:30:00.160
these are
01:30:00.160 --> 01:30:00.820
the same
01:30:00.820 --> 01:30:01.280
implementations
01:30:01.860 --> 01:30:02.480
it's just
01:30:02.480 --> 01:30:02.880
that
01:30:02.880 --> 01:30:03.280
it's an
01:30:03.280 --> 01:30:03.680
another
01:30:03.680 --> 01:30:03.980
file
01:30:03.980 --> 01:30:04.640
it serves
01:30:04.640 --> 01:30:04.860
another
01:30:04.860 --> 01:30:05.380
purpose
01:30:05.380 --> 01:30:06.080
that's all
01:30:07.680 --> 01:30:08.320
okay
01:30:09.880 --> 01:30:10.520
yeah
01:30:10.520 --> 01:30:11.200
just a
01:30:11.200 --> 01:30:11.460
moment
01:30:12.220 --> 01:30:12.900
so yeah
01:30:12.900 --> 01:30:13.480
till now
01:30:13.480 --> 01:30:14.280
we just
01:30:14.280 --> 01:30:14.780
gone through
01:30:15.460 --> 01:30:15.840
a
01:30:15.840 --> 01:30:16.440
specification
01:30:17.340 --> 01:30:17.980
how
01:30:17.980 --> 01:30:18.660
an APA
01:30:18.660 --> 01:30:19.140
specification
01:30:19.140 --> 01:30:19.700
should be
01:30:19.700 --> 01:30:20.400
or
01:30:20.400 --> 01:30:20.620
what
01:30:20.620 --> 01:30:20.940
exactly
01:30:21.640 --> 01:30:22.280
the
01:30:22.280 --> 01:30:22.520
keys
01:30:22.520 --> 01:30:22.900
or what
01:30:22.900 --> 01:30:23.520
what exactly
01:30:23.520 --> 01:30:23.760
the
01:30:23.760 --> 01:30:24.020
values
01:30:24.020 --> 01:30:24.300
should be
01:30:25.040 --> 01:30:25.820
what exactly
01:30:25.820 --> 01:30:26.320
the pattern
01:30:26.320 --> 01:30:26.760
should be
01:30:26.760 --> 01:30:27.220
at all
01:30:27.220 --> 01:30:27.700
but
01:30:27.700 --> 01:30:28.040
till now
01:30:28.040 --> 01:30:28.540
we haven't
01:30:28.540 --> 01:30:29.000
gone through
01:30:29.000 --> 01:30:29.180
any
01:30:30.120 --> 01:30:30.540
route
01:30:30.540 --> 01:30:31.180
specifically
01:30:31.180 --> 01:30:31.580
till now
01:30:32.360 --> 01:30:33.000
so
01:30:33.000 --> 01:30:33.440
but
01:30:33.440 --> 01:30:34.240
if we
01:30:34.860 --> 01:30:35.440
discuss
01:30:35.440 --> 01:30:36.640
that we
01:30:36.640 --> 01:30:37.260
gonna follow
01:30:37.260 --> 01:30:37.960
REST API
01:30:37.960 --> 01:30:38.500
I think
01:30:38.500 --> 01:30:38.960
REST API
01:30:38.960 --> 01:30:39.460
implementation
01:30:39.460 --> 01:30:39.780
here
01:30:39.780 --> 01:30:40.320
right
01:30:40.320 --> 01:30:40.480
so
01:30:40.480 --> 01:30:40.840
for this
01:30:40.840 --> 01:30:41.240
REST API
01:30:41.240 --> 01:30:42.060
implementation
01:30:42.060 --> 01:30:42.700
a route
01:30:42.700 --> 01:30:43.160
should be
01:30:43.160 --> 01:30:43.420
an
01:30:43.420 --> 01:30:43.920
important
01:30:43.920 --> 01:30:44.280
point
01:30:44.280 --> 01:30:44.760
or
01:30:44.760 --> 01:30:45.380
okay
01:30:46.160 --> 01:30:46.300
so
01:30:46.860 --> 01:30:47.620
what exactly
01:30:47.620 --> 01:30:47.920
is a
01:30:47.920 --> 01:30:48.300
route
01:30:49.340 --> 01:30:50.320
a route
01:30:50.320 --> 01:30:50.460
is
01:30:51.640 --> 01:30:52.600
a place
01:30:52.600 --> 01:30:52.880
where
01:30:52.880 --> 01:30:53.420
we host
01:30:53.420 --> 01:30:53.620
up
01:30:53.620 --> 01:30:53.980
API
01:30:54.620 --> 01:30:55.140
so
01:30:55.140 --> 01:30:55.720
let's say
01:30:55.720 --> 01:30:56.400
you have
01:30:56.400 --> 01:30:57.080
a couple of
01:30:57.080 --> 01:30:57.480
APS
01:30:57.480 --> 01:30:58.520
let's say
01:30:58.520 --> 01:30:58.920
product
01:30:58.920 --> 01:30:59.420
API
01:31:00.340 --> 01:31:01.040
which
01:31:01.040 --> 01:31:01.460
provides
01:31:01.460 --> 01:31:02.480
a list of
01:31:02.480 --> 01:31:02.940
all the
01:31:02.940 --> 01:31:03.160
products
01:31:03.160 --> 01:31:03.880
but
01:31:03.880 --> 01:31:04.360
again
01:31:04.860 --> 01:31:05.840
one of the
01:31:05.840 --> 01:31:06.400
best practice
01:31:06.400 --> 01:31:07.460
to design
01:31:07.460 --> 01:31:08.080
an API
01:31:08.080 --> 01:31:08.980
is to
01:31:08.980 --> 01:31:09.540
you should
01:31:09.540 --> 01:31:10.080
not use
01:31:10.080 --> 01:31:10.740
plurals over
01:31:10.740 --> 01:31:10.960
here
01:31:10.960 --> 01:31:11.340
you should
01:31:11.340 --> 01:31:11.740
only use
01:31:13.020 --> 01:31:13.560
singulars
01:31:13.560 --> 01:31:14.640
that is
01:31:14.640 --> 01:31:15.800
one of the
01:31:15.800 --> 01:31:16.460
best practice
01:31:16.460 --> 01:31:17.080
to maintain
01:31:17.080 --> 01:31:17.980
uniformity
01:31:17.980 --> 01:31:18.460
across
01:31:18.460 --> 01:31:20.340
all the
01:31:20.340 --> 01:31:22.700
you know
01:31:22.700 --> 01:31:22.980
routes
01:31:22.980 --> 01:31:23.380
that you
01:31:23.380 --> 01:31:23.960
wanna design
01:31:23.960 --> 01:31:24.720
okay
01:31:24.720 --> 01:31:25.660
that is one thing
01:31:25.660 --> 01:31:25.940
and
01:31:25.940 --> 01:31:26.520
let's say
01:31:26.520 --> 01:31:27.340
this product
01:31:27.340 --> 01:31:28.500
gives you
01:31:28.500 --> 01:31:29.100
a list of
01:31:29.100 --> 01:31:29.380
products
01:31:29.380 --> 01:31:30.500
so let's say
01:31:30.500 --> 01:31:31.880
you wanted to have
01:31:31.880 --> 01:31:32.660
a specific
01:31:32.660 --> 01:31:33.020
product
01:31:33.020 --> 01:31:34.160
and how it
01:31:34.160 --> 01:31:34.380
works
01:31:35.900 --> 01:31:36.620
so
01:31:40.380 --> 01:31:41.280
so this
01:31:41.280 --> 01:31:41.800
curly-based
01:31:41.800 --> 01:31:42.340
syntax
01:31:42.340 --> 01:31:42.940
provides you
01:31:46.500 --> 01:31:47.600
a variable
01:31:47.600 --> 01:31:48.060
here
01:31:48.060 --> 01:31:48.480
so
01:31:48.480 --> 01:31:49.060
this is not
01:31:49.060 --> 01:31:49.460
hard-coded
01:31:49.460 --> 01:31:50.160
to product one
01:31:50.160 --> 01:31:50.940
that might be
01:31:51.660 --> 01:31:52.240
a clothes
01:31:52.240 --> 01:31:52.460
or
01:31:53.240 --> 01:31:53.580
product
01:31:53.580 --> 01:31:54.080
slash
01:31:54.080 --> 01:31:54.580
chocolates
01:31:54.580 --> 01:31:55.040
or product
01:31:55.040 --> 01:31:55.260
slash
01:31:56.020 --> 01:31:56.540
biscuits
01:31:56.540 --> 01:31:56.960
or
01:31:56.960 --> 01:31:57.320
anything
01:31:57.320 --> 01:31:58.500
which is
01:31:58.500 --> 01:31:58.840
specific
01:31:58.840 --> 01:31:59.480
to
01:31:59.480 --> 01:32:00.160
that specific
01:32:00.160 --> 01:32:00.640
implementation
01:32:01.180 --> 01:32:01.740
and
01:32:01.740 --> 01:32:02.400
we can also
01:32:02.400 --> 01:32:03.020
have
01:32:03.020 --> 01:32:03.940
or
01:32:03.940 --> 01:32:04.260
delete
01:32:04.260 --> 01:32:04.840
as well
01:32:04.860 --> 01:32:05.980
like each
01:32:05.980 --> 01:32:06.720
and every
01:32:06.720 --> 01:32:07.220
route
01:32:07.980 --> 01:32:08.540
is
01:32:08.540 --> 01:32:08.920
associated
01:32:08.920 --> 01:32:09.260
with their
01:32:11.700 --> 01:32:12.540
API request
01:32:12.540 --> 01:32:12.980
basically
01:32:12.980 --> 01:32:13.780
so for product
01:32:13.780 --> 01:32:14.560
it's like
01:32:14.560 --> 01:32:15.260
get API
01:32:16.620 --> 01:32:18.140
and for
01:32:18.140 --> 01:32:18.400
getting
01:32:18.400 --> 01:32:19.240
each product
01:32:19.240 --> 01:32:19.680
we have
01:32:19.680 --> 01:32:20.400
a get API
01:32:21.180 --> 01:32:21.780
and
01:32:21.780 --> 01:32:22.300
let's say
01:32:22.300 --> 01:32:22.960
for
01:32:22.960 --> 01:32:23.340
creating
01:32:23.340 --> 01:32:24.260
a new product
01:32:24.780 --> 01:32:25.260
we have
01:32:25.260 --> 01:32:26.180
a post API
01:32:26.700 --> 01:32:27.140
but
01:32:27.140 --> 01:32:27.880
only product
01:32:27.880 --> 01:32:28.340
endpoint
01:32:29.020 --> 01:32:29.420
I think
01:32:29.420 --> 01:32:32.520
I don't
01:32:32.520 --> 01:32:32.760
wait
01:32:32.760 --> 01:32:33.960
let me just
01:32:36.580 --> 01:32:37.300
and
01:32:37.300 --> 01:32:37.880
you can also
01:32:37.880 --> 01:32:38.040
have
01:32:38.820 --> 01:32:39.100
or
01:32:39.100 --> 01:32:39.380
delete
01:32:39.380 --> 01:32:39.720
API
01:32:42.860 --> 01:32:43.580
slash
01:32:43.580 --> 01:32:43.880
product
01:32:44.460 --> 01:32:45.280
slash
01:32:45.280 --> 01:32:45.720
product
01:32:45.720 --> 01:32:46.180
ID
01:32:48.160 --> 01:32:48.280
and
01:32:48.880 --> 01:32:49.500
you wanted
01:32:49.500 --> 01:32:49.900
to
01:32:49.900 --> 01:32:50.120
edit
01:32:50.120 --> 01:32:50.600
a specific
01:32:50.600 --> 01:32:51.000
product
01:32:51.000 --> 01:32:51.400
which is
01:32:51.400 --> 01:32:51.620
already
01:32:51.620 --> 01:32:51.900
there
01:32:51.900 --> 01:32:52.180
inside
01:32:52.180 --> 01:32:52.400
the
01:32:52.400 --> 01:32:52.680
application
01:32:53.200 --> 01:32:53.880
in that
01:32:53.880 --> 01:32:54.340
scenario
01:32:55.160 --> 01:32:55.720
we have
01:32:55.720 --> 01:32:55.940
put
01:32:55.940 --> 01:32:56.200
API
01:32:59.900 --> 01:33:00.620
so
01:33:00.620 --> 01:33:00.920
yeah
01:33:00.920 --> 01:33:01.920
these are
01:33:01.920 --> 01:33:02.320
different
01:33:02.320 --> 01:33:02.680
APIs
01:33:02.680 --> 01:33:03.080
that you
01:33:04.680 --> 01:33:05.360
inside
01:33:05.360 --> 01:33:05.700
your
01:33:05.700 --> 01:33:05.980
route
01:33:05.980 --> 01:33:06.620
project
01:33:06.620 --> 01:33:07.240
so
01:33:07.240 --> 01:33:07.600
if you
01:33:07.600 --> 01:33:07.960
go
01:33:07.960 --> 01:33:08.220
over
01:33:08.220 --> 01:33:08.340
here
01:33:08.340 --> 01:33:08.520
so
01:33:08.520 --> 01:33:08.700
we'll
01:33:08.700 --> 01:33:08.880
be
01:33:08.880 --> 01:33:09.240
designing
01:33:09.240 --> 01:33:09.760
a couple
01:33:09.760 --> 01:33:09.800
of
01:33:10.700 --> 01:33:11.080
APIs
01:33:11.800 --> 01:33:12.180
so
01:33:12.180 --> 01:33:13.100
let's say
01:33:13.100 --> 01:33:13.240
for
01:33:14.120 --> 01:33:14.800
categories
01:33:14.800 --> 01:33:15.320
API
01:33:16.120 --> 01:33:17.020
let me
01:33:17.020 --> 01:33:17.240
just
01:33:17.240 --> 01:33:17.540
first
01:33:17.540 --> 01:33:17.880
describe
01:33:17.880 --> 01:33:18.080
you
01:33:18.080 --> 01:33:18.300
on
01:33:18.300 --> 01:33:18.720
products
01:33:18.720 --> 01:33:19.360
scenario
01:33:20.440 --> 01:33:20.860
I mean
01:33:20.860 --> 01:33:21.360
that will
01:33:21.360 --> 01:33:21.580
be
01:33:21.580 --> 01:33:21.880
mostly
01:33:21.880 --> 01:33:22.220
same
01:33:22.220 --> 01:33:22.280
for
01:33:23.160 --> 01:33:23.420
others
01:33:23.420 --> 01:33:23.980
as well
01:33:23.980 --> 01:33:24.800
so
01:33:24.800 --> 01:33:25.360
this
01:33:25.360 --> 01:33:26.020
get
01:33:26.760 --> 01:33:27.520
this is
01:33:27.520 --> 01:33:27.740
API
01:33:27.740 --> 01:33:28.140
method
01:33:28.140 --> 01:33:28.680
basically
01:33:28.680 --> 01:33:29.680
and
01:33:29.680 --> 01:33:29.960
the
01:33:29.960 --> 01:33:30.180
next
01:33:30.180 --> 01:33:30.560
one is
01:33:30.560 --> 01:33:30.860
route
01:33:30.860 --> 01:33:31.820
so
01:33:31.820 --> 01:33:32.360
an API
01:33:32.360 --> 01:33:32.820
method
01:33:32.820 --> 01:33:33.440
and a
01:33:33.440 --> 01:33:33.620
route
01:33:33.620 --> 01:33:33.920
should
01:33:33.920 --> 01:33:34.340
always
01:33:34.340 --> 01:33:34.700
coupled
01:33:34.700 --> 01:33:34.880
with
01:33:34.880 --> 01:33:35.200
each other
01:33:36.360 --> 01:33:36.760
a
01:33:36.760 --> 01:33:37.020
route
01:33:37.020 --> 01:33:37.480
without
01:33:37.480 --> 01:33:37.740
an
01:33:37.740 --> 01:33:37.900
API
01:33:37.900 --> 01:33:38.380
method
01:33:38.380 --> 01:33:38.840
is
01:33:38.840 --> 01:33:39.300
meaningless
01:33:40.160 --> 01:33:40.520
they
01:33:40.520 --> 01:33:40.680
should
01:33:40.680 --> 01:33:40.940
be
01:33:40.940 --> 01:33:41.260
always
01:33:41.260 --> 01:33:41.480
coupled
01:33:41.480 --> 01:33:41.700
with
01:33:41.700 --> 01:33:41.860
each
01:33:41.860 --> 01:33:42.240
other
01:33:42.240 --> 01:33:42.940
okay
01:33:42.940 --> 01:33:43.380
that's
01:33:43.380 --> 01:33:43.460
how
01:33:43.460 --> 01:33:43.900
it
01:33:43.900 --> 01:33:44.100
works
01:33:44.100 --> 01:33:44.600
in
01:33:44.600 --> 01:33:44.880
general
01:33:44.880 --> 01:33:45.360
scenarios
01:33:45.360 --> 01:33:45.960
basically
01:33:47.280 --> 01:33:47.980
and
01:33:47.980 --> 01:33:48.780
let's
01:33:48.780 --> 01:33:49.000
say
01:33:49.000 --> 01:33:49.220
you
01:33:49.220 --> 01:33:49.340
wanted
01:33:49.340 --> 01:33:49.920
to
01:33:49.920 --> 01:33:50.040
get
01:33:50.040 --> 01:33:50.280
all
01:33:50.280 --> 01:33:50.540
products
01:33:50.540 --> 01:33:50.880
then
01:33:50.880 --> 01:33:51.140
you
01:33:51.140 --> 01:33:51.520
hit
01:33:51.520 --> 01:33:51.960
get
01:33:51.960 --> 01:33:52.160
API
01:33:52.160 --> 01:33:52.440
with
01:33:52.440 --> 01:33:52.700
all
01:33:52.700 --> 01:33:53.100
products
01:33:53.100 --> 01:33:54.000
and
01:33:54.000 --> 01:33:54.080
for
01:33:55.060 --> 01:33:55.680
get
01:33:55.680 --> 01:33:55.900
a
01:33:55.900 --> 01:33:56.120
single
01:33:56.120 --> 01:33:56.540
product
01:33:57.120 --> 01:33:57.600
we can
01:33:57.600 --> 01:33:58.120
hit
01:33:58.120 --> 01:33:58.940
get
01:33:58.940 --> 01:33:59.320
product
01:33:59.320 --> 01:33:59.600
and
01:33:59.600 --> 01:34:00.420
product
01:34:00.420 --> 01:34:00.900
ID
01:34:00.900 --> 01:34:01.800
and
01:34:01.800 --> 01:34:02.060
for
01:34:02.060 --> 01:34:02.380
posting
01:34:02.380 --> 01:34:02.920
a product
01:34:04.220 --> 01:34:04.900
we'll
01:34:04.900 --> 01:34:05.340
be
01:34:05.340 --> 01:34:05.860
passing
01:34:05.860 --> 01:34:06.480
a payload
01:34:06.480 --> 01:34:07.100
over here
01:34:07.100 --> 01:34:07.900
if you see
01:34:07.900 --> 01:34:08.360
over here
01:34:08.360 --> 01:34:08.680
for
01:34:08.680 --> 01:34:09.440
post request
01:34:10.160 --> 01:34:10.740
we don't
01:34:10.740 --> 01:34:11.000
have
01:34:11.000 --> 01:34:11.260
any
01:34:11.260 --> 01:34:11.660
slash
01:34:11.660 --> 01:34:12.140
after
01:34:12.140 --> 01:34:12.500
product
01:34:12.500 --> 01:34:12.900
and
01:34:12.900 --> 01:34:13.240
payload
01:34:13.240 --> 01:34:13.900
so
01:34:13.900 --> 01:34:14.280
what I mean
01:34:14.280 --> 01:34:14.640
to say
01:34:14.640 --> 01:34:14.840
is
01:34:14.840 --> 01:34:15.620
basically
01:34:15.620 --> 01:34:16.040
payload
01:34:16.040 --> 01:34:16.620
is
01:34:16.620 --> 01:34:16.920
something
01:34:16.920 --> 01:34:17.260
we'll
01:34:17.260 --> 01:34:17.460
be
01:34:17.460 --> 01:34:17.640
giving
01:34:17.640 --> 01:34:18.040
inside
01:34:18.040 --> 01:34:18.380
the
01:34:18.380 --> 01:34:18.900
body
01:34:19.520 --> 01:34:20.160
so
01:34:20.160 --> 01:34:20.700
for this
01:34:20.700 --> 01:34:20.860
you need
01:34:20.860 --> 01:34:21.040
to
01:34:21.040 --> 01:34:21.400
understand
01:34:21.400 --> 01:34:21.800
one of
01:34:21.800 --> 01:34:21.920
the
01:34:21.920 --> 01:34:22.360
prerequisite
01:34:23.120 --> 01:34:23.800
like
01:34:23.800 --> 01:34:24.460
what are
01:34:24.460 --> 01:34:24.640
headers
01:34:26.080 --> 01:34:27.040
what are
01:34:27.040 --> 01:34:27.280
URA
01:34:29.100 --> 01:34:30.000
what are
01:34:30.000 --> 01:34:30.580
headers
01:34:31.840 --> 01:34:32.740
what is
01:34:32.740 --> 01:34:33.080
body
01:34:35.160 --> 01:34:35.960
so
01:34:35.960 --> 01:34:36.440
basically
01:34:36.440 --> 01:34:37.180
an URA
01:34:37.180 --> 01:34:37.780
is a
01:34:37.780 --> 01:34:38.220
location
01:34:38.220 --> 01:34:38.500
where
01:34:38.500 --> 01:34:38.780
you are
01:34:38.780 --> 01:34:39.120
hitting
01:34:39.120 --> 01:34:40.100
an
01:34:40.100 --> 01:34:40.400
API
01:34:40.400 --> 01:34:41.280
okay
01:34:41.280 --> 01:34:41.860
and
01:34:41.860 --> 01:34:42.040
the
01:34:42.040 --> 01:34:42.420
headers
01:34:42.420 --> 01:34:42.900
are
01:34:42.900 --> 01:34:43.120
some
01:34:43.120 --> 01:34:43.500
things
01:34:43.500 --> 01:34:44.320
that
01:34:44.320 --> 01:34:44.500
you're
01:34:44.500 --> 01:34:44.780
going to
01:34:44.780 --> 01:34:45.280
pass
01:34:45.280 --> 01:34:45.680
to
01:34:45.680 --> 01:34:45.940
that
01:34:45.940 --> 01:34:46.520
URA
01:34:46.520 --> 01:34:46.820
while
01:34:46.820 --> 01:34:47.260
you are
01:34:47.260 --> 01:34:47.520
hitting
01:34:47.520 --> 01:34:47.600
the
01:34:48.540 --> 01:34:48.900
web
01:34:48.900 --> 01:34:49.480
request
01:34:49.480 --> 01:34:50.080
and
01:34:50.880 --> 01:34:51.300
typically
01:34:51.300 --> 01:34:51.900
headers
01:34:51.900 --> 01:34:52.200
mostly
01:34:52.200 --> 01:34:52.820
consists of
01:34:52.820 --> 01:34:53.280
authentication
01:34:53.280 --> 01:34:53.840
authorization
01:34:53.840 --> 01:34:54.400
mechanisms
01:34:54.400 --> 01:34:55.040
and
01:34:55.720 --> 01:34:56.440
some
01:34:56.440 --> 01:34:56.860
of
01:34:56.860 --> 01:34:57.600
the
01:34:57.600 --> 01:34:58.160
and
01:34:58.160 --> 01:34:58.560
you'll
01:34:58.560 --> 01:34:58.700
be
01:34:58.700 --> 01:34:58.960
hitting
01:34:58.960 --> 01:34:59.580
this
01:34:59.580 --> 01:35:00.280
specific
01:35:00.280 --> 01:35:01.360
API request
01:35:01.360 --> 01:35:01.640
with the
01:35:01.640 --> 01:35:02.080
help of
01:35:02.080 --> 01:35:02.820
API client
01:35:02.820 --> 01:35:03.800
so
01:35:03.800 --> 01:35:04.840
API client
01:35:05.400 --> 01:35:06.260
in mostly
01:35:06.260 --> 01:35:06.940
you will be
01:35:06.940 --> 01:35:07.220
having
01:35:08.000 --> 01:35:08.600
postman
01:35:10.620 --> 01:35:11.560
let's just
01:35:11.560 --> 01:35:12.080
keep it under
01:35:12.080 --> 01:35:12.380
tool
01:35:12.380 --> 01:35:12.740
thing
01:35:12.740 --> 01:35:13.780
you have to
01:35:13.780 --> 01:35:14.120
understand
01:35:14.120 --> 01:35:14.520
postman
01:35:14.520 --> 01:35:17.180
as well
01:35:18.520 --> 01:35:19.120
so
01:35:19.120 --> 01:35:19.340
postman
01:35:19.340 --> 01:35:19.640
is a
01:35:19.640 --> 01:35:19.800
tool
01:35:19.800 --> 01:35:20.300
which is
01:35:20.300 --> 01:35:20.480
an
01:35:20.480 --> 01:35:21.000
API
01:35:21.000 --> 01:35:21.540
client
01:35:22.120 --> 01:35:22.520
which
01:35:22.520 --> 01:35:22.840
basically
01:35:23.760 --> 01:35:24.740
helps us to
01:35:24.740 --> 01:35:25.080
hit an
01:35:25.080 --> 01:35:25.380
API
01:35:25.380 --> 01:35:25.740
while
01:35:25.740 --> 01:35:26.040
testing
01:35:26.040 --> 01:35:26.120
it
01:35:27.020 --> 01:35:27.980
we have
01:35:27.980 --> 01:35:28.480
I mean
01:35:28.480 --> 01:35:28.800
I have
01:35:28.800 --> 01:35:29.080
created
01:35:29.080 --> 01:35:29.240
that
01:35:30.000 --> 01:35:30.720
one of
01:35:31.640 --> 01:35:32.240
the
01:35:32.240 --> 01:35:32.800
hands-on
01:35:32.800 --> 01:35:33.300
application
01:35:33.300 --> 01:35:33.720
as well
01:35:33.720 --> 01:35:34.360
hands-on
01:35:34.360 --> 01:35:34.800
is
01:35:34.800 --> 01:35:35.140
implementation
01:35:35.140 --> 01:35:35.480
as well
01:35:35.480 --> 01:35:36.360
for that
01:35:36.360 --> 01:35:36.920
for API
01:35:36.920 --> 01:35:37.640
for postman
01:35:38.320 --> 01:35:38.980
which is
01:35:38.980 --> 01:35:39.380
tightly
01:35:39.380 --> 01:35:39.680
coupled
01:35:39.680 --> 01:35:40.020
with the
01:35:40.020 --> 01:35:40.420
mule soft
01:35:41.760 --> 01:35:42.240
and
01:35:42.240 --> 01:35:42.600
yeah
01:35:42.600 --> 01:35:42.920
we'll be
01:35:42.920 --> 01:35:43.320
passing headers
01:35:43.320 --> 01:35:43.720
with that
01:35:43.720 --> 01:35:44.040
and
01:35:44.040 --> 01:35:44.560
the body
01:35:44.560 --> 01:35:44.920
is
01:35:44.920 --> 01:35:45.580
actual payload
01:35:45.580 --> 01:35:46.260
that we want to
01:35:46.260 --> 01:35:46.500
pass
01:35:46.500 --> 01:35:47.080
like
01:35:47.080 --> 01:35:47.620
the details
01:35:47.620 --> 01:35:48.440
of the
01:35:48.440 --> 01:35:48.820
product
01:35:49.360 --> 01:35:49.840
like
01:35:49.840 --> 01:35:50.160
the name
01:35:50.160 --> 01:35:50.460
of the
01:35:50.460 --> 01:35:50.700
product
01:35:50.700 --> 01:35:50.960
the
01:35:50.960 --> 01:35:51.240
description
01:35:51.240 --> 01:35:51.620
of the
01:35:51.620 --> 01:35:51.860
product
01:35:51.860 --> 01:35:52.240
and
01:35:52.240 --> 01:35:52.460
price
01:35:52.460 --> 01:35:52.840
of the
01:35:52.840 --> 01:35:53.060
product
01:35:53.060 --> 01:35:53.700
and all
01:35:53.700 --> 01:35:54.180
all those
01:35:54.180 --> 01:35:54.340
things
01:35:54.340 --> 01:35:54.720
we'll be
01:35:54.720 --> 01:35:54.900
providing
01:35:54.900 --> 01:35:55.600
over there
01:35:55.600 --> 01:35:56.060
inside the
01:35:56.060 --> 01:35:56.220
body
01:35:56.220 --> 01:35:56.620
itself
01:35:57.160 --> 01:35:57.640
and
01:35:57.640 --> 01:35:58.080
you also
01:35:58.080 --> 01:35:58.540
have this
01:35:58.540 --> 01:35:58.920
delete
01:36:00.340 --> 01:36:01.020
if you
01:36:01.020 --> 01:36:01.400
want to
01:36:01.400 --> 01:36:01.700
specify
01:36:01.700 --> 01:36:02.120
or
01:36:02.120 --> 01:36:02.560
delete
01:36:02.560 --> 01:36:03.500
a specific
01:36:03.500 --> 01:36:04.240
work
01:36:04.240 --> 01:36:05.020
inside the database
01:36:05.020 --> 01:36:05.640
then we will be
01:36:05.640 --> 01:36:06.060
hitting this
01:36:06.060 --> 01:36:06.600
delete API
01:36:06.600 --> 01:36:07.260
and then
01:36:08.660 --> 01:36:09.600
if you see
01:36:09.600 --> 01:36:10.060
over here
01:36:10.060 --> 01:36:10.540
put and
01:36:10.540 --> 01:36:10.900
post
01:36:10.900 --> 01:36:11.740
mostly
01:36:11.740 --> 01:36:12.200
does the
01:36:12.200 --> 01:36:12.700
same thing
01:36:12.700 --> 01:36:13.400
then what
01:36:13.400 --> 01:36:13.900
exactly is the
01:36:13.900 --> 01:36:14.060
difference
01:36:14.060 --> 01:36:14.320
between
01:36:14.320 --> 01:36:14.740
post and
01:36:14.740 --> 01:36:15.160
put and
01:36:15.160 --> 01:36:15.460
post
01:36:15.460 --> 01:36:16.280
so basically
01:36:16.280 --> 01:36:16.920
put
01:36:18.740 --> 01:36:19.260
basically
01:36:19.260 --> 01:36:19.720
doesn't
01:36:19.720 --> 01:36:20.500
care about
01:36:20.500 --> 01:36:21.100
what exactly
01:36:21.100 --> 01:36:21.420
is
01:36:21.420 --> 01:36:21.680
already
01:36:21.680 --> 01:36:22.380
there
01:36:22.380 --> 01:36:23.080
inside the
01:36:23.080 --> 01:36:23.520
system
01:36:23.520 --> 01:36:24.460
you don't
01:36:24.460 --> 01:36:24.880
care about
01:36:24.880 --> 01:36:25.300
that
01:36:25.300 --> 01:36:25.980
you don't
01:36:25.980 --> 01:36:26.360
care about
01:36:26.360 --> 01:36:26.460
them
01:36:27.100 --> 01:36:27.620
whatever
01:36:27.620 --> 01:36:28.220
you care
01:36:28.220 --> 01:36:28.580
I mean
01:36:28.580 --> 01:36:28.820
whatever
01:36:28.820 --> 01:36:29.280
you provide
01:36:29.280 --> 01:36:29.600
to
01:36:29.600 --> 01:36:29.820
put
01:36:29.820 --> 01:36:30.300
as a
01:36:30.300 --> 01:36:30.580
payload
01:36:31.280 --> 01:36:32.120
it just
01:36:32.120 --> 01:36:32.540
takes them
01:36:33.500 --> 01:36:33.980
to the
01:36:34.540 --> 01:36:34.980
if it is
01:36:34.980 --> 01:36:35.440
I mean
01:36:35.440 --> 01:36:36.000
if there are
01:36:36.000 --> 01:36:36.220
already
01:36:36.220 --> 01:36:36.780
resources that
01:36:36.780 --> 01:36:37.080
are already
01:36:37.080 --> 01:36:37.400
present
01:36:37.400 --> 01:36:37.960
inside
01:36:38.700 --> 01:36:39.020
database
01:36:39.020 --> 01:36:39.840
it just
01:36:39.840 --> 01:36:40.240
overrides
01:36:40.240 --> 01:36:40.580
them
01:36:41.240 --> 01:36:41.880
without
01:36:41.880 --> 01:36:42.540
caring
01:36:42.540 --> 01:36:42.840
about
01:36:42.840 --> 01:36:43.220
them
01:36:43.220 --> 01:36:43.680
but
01:36:43.680 --> 01:36:44.100
post is
01:36:44.100 --> 01:36:44.560
not like
01:36:44.560 --> 01:36:45.080
that
01:36:45.080 --> 01:36:45.700
post provides
01:36:45.700 --> 01:36:46.040
the
01:36:46.040 --> 01:36:46.360
appending
01:36:46.360 --> 01:36:46.920
operation
01:36:46.920 --> 01:36:47.280
rather
01:36:47.280 --> 01:36:47.640
than
01:36:47.640 --> 01:36:48.040
overwriting
01:36:48.040 --> 01:36:48.560
operation
01:36:49.180 --> 01:36:49.500
so one
01:36:49.500 --> 01:36:49.900
has to
01:36:50.540 --> 01:36:50.600
do
01:36:50.600 --> 01:36:51.100
more
01:36:51.100 --> 01:36:51.460
careful
01:36:51.460 --> 01:36:51.900
operations
01:36:51.900 --> 01:36:52.320
with the
01:36:52.320 --> 01:36:52.480
post
01:36:53.100 --> 01:36:53.320
put
01:36:53.320 --> 01:36:53.780
API
01:36:53.780 --> 01:36:54.500
when it
01:37:03.500 --> 01:37:04.000
we're
01:37:04.000 --> 01:37:04.160
good
01:37:04.160 --> 01:37:05.260
to go
01:37:07.160 --> 01:37:07.840
okay
01:37:07.840 --> 01:37:08.440
cool
01:37:08.440 --> 01:37:09.000
yeah
01:37:09.000 --> 01:37:09.740
so
01:37:09.740 --> 01:37:10.080
let's
01:37:10.080 --> 01:37:10.700
come to
01:37:10.700 --> 01:37:10.980
raml
01:37:10.980 --> 01:37:11.500
definitions
01:37:11.500 --> 01:37:12.360
and
01:37:12.360 --> 01:37:13.140
how these
01:37:13.140 --> 01:37:13.460
things
01:37:13.460 --> 01:37:13.780
works
01:37:13.780 --> 01:37:14.340
with raml
01:37:14.340 --> 01:37:14.700
basically
01:37:15.900 --> 01:37:16.580
so
01:37:16.580 --> 01:37:16.980
we wanted
01:37:16.980 --> 01:37:17.320
to
01:37:17.320 --> 01:37:17.840
create
01:37:17.840 --> 01:37:18.160
a
01:37:18.160 --> 01:37:18.400
mule soft
01:37:18.400 --> 01:37:19.200
application
01:37:19.900 --> 01:37:20.520
which
01:37:20.520 --> 01:37:20.840
does
01:37:20.840 --> 01:37:21.140
all
01:37:21.140 --> 01:37:21.360
these
01:37:21.360 --> 01:37:21.500
things
01:37:22.660 --> 01:37:23.240
whatever
01:37:23.240 --> 01:37:23.680
I told
01:37:23.680 --> 01:37:23.980
right
01:37:23.980 --> 01:37:24.540
now
01:37:24.540 --> 01:37:25.000
with the
01:37:25.000 --> 01:37:25.180
help
01:37:25.180 --> 01:37:25.680
of
01:37:25.680 --> 01:37:25.740
just
01:37:26.740 --> 01:37:27.140
yaml
01:37:27.140 --> 01:37:27.340
based
01:37:27.340 --> 01:37:27.780
syntax
01:37:27.780 --> 01:37:28.620
that's
01:37:28.620 --> 01:37:28.740
how
01:37:28.740 --> 01:37:29.080
we'll
01:37:29.080 --> 01:37:29.460
be
01:37:29.460 --> 01:37:30.180
designing
01:37:31.120 --> 01:37:31.800
our
01:37:31.800 --> 01:37:32.340
APIs
01:37:32.340 --> 01:37:32.900
over here
01:37:33.500 --> 01:37:33.880
over
01:37:35.060 --> 01:37:35.740
here
01:37:35.740 --> 01:37:36.360
so
01:37:36.360 --> 01:37:36.800
basically
01:37:36.800 --> 01:37:37.300
we have
01:37:37.300 --> 01:37:37.580
this
01:37:37.580 --> 01:37:37.860
parent
01:37:37.860 --> 01:37:38.100
route
01:37:38.100 --> 01:37:39.100
so
01:37:39.100 --> 01:37:39.400
inside
01:37:39.400 --> 01:37:39.660
the
01:37:39.660 --> 01:37:40.280
raml
01:37:40.280 --> 01:37:40.880
we have
01:37:40.880 --> 01:37:41.060
the
01:37:41.060 --> 01:37:41.400
syntax
01:37:41.400 --> 01:37:41.760
called
01:37:41.760 --> 01:37:42.140
parent
01:37:42.140 --> 01:37:42.400
route
01:37:42.400 --> 01:37:42.900
and
01:37:42.900 --> 01:37:43.220
child
01:37:43.220 --> 01:37:43.560
route
01:37:44.140 --> 01:37:44.580
so
01:37:44.580 --> 01:37:44.920
basically
01:37:44.920 --> 01:37:45.320
this
01:37:45.320 --> 01:37:45.600
parent
01:37:45.600 --> 01:37:46.040
route
01:37:46.040 --> 01:37:46.400
consists
01:37:46.400 --> 01:37:46.680
of
01:37:46.680 --> 01:37:48.620
all the
01:37:48.620 --> 01:37:49.260
responses
01:37:49.260 --> 01:37:49.620
or
01:37:49.620 --> 01:37:50.180
descriptions
01:37:51.020 --> 01:37:51.400
that
01:37:51.400 --> 01:37:51.760
we're
01:37:51.760 --> 01:37:52.060
to
01:37:52.060 --> 01:37:52.380
provide
01:37:52.380 --> 01:37:53.100
and
01:37:53.100 --> 01:37:53.340
the
01:37:53.340 --> 01:37:53.520
child
01:37:53.520 --> 01:37:53.760
routes
01:37:53.760 --> 01:37:53.980
will
01:37:53.980 --> 01:37:54.520
be
01:37:54.520 --> 01:37:54.840
appending
01:37:54.840 --> 01:37:55.120
to
01:37:55.120 --> 01:37:55.560
the
01:37:55.560 --> 01:37:56.220
parent
01:37:56.220 --> 01:37:56.520
route
01:37:56.520 --> 01:37:57.200
so
01:37:57.200 --> 01:37:57.540
let's
01:37:57.540 --> 01:37:57.820
say
01:37:57.820 --> 01:37:58.480
we have
01:37:58.480 --> 01:37:59.040
categories
01:38:00.300 --> 01:38:00.980
so
01:38:00.980 --> 01:38:01.220
let's
01:38:01.220 --> 01:38:01.320
say
01:38:01.320 --> 01:38:01.780
we have
01:38:01.780 --> 01:38:02.040
few
01:38:02.040 --> 01:38:02.540
categories
01:38:02.540 --> 01:38:03.100
here
01:38:03.100 --> 01:38:03.480
and
01:38:04.120 --> 01:38:04.640
user
01:38:04.640 --> 01:38:05.180
wants to
01:38:05.180 --> 01:38:05.380
get
01:38:05.380 --> 01:38:05.860
categories
01:38:05.860 --> 01:38:06.780
so
01:38:06.780 --> 01:38:07.140
in that
01:38:07.880 --> 01:38:08.400
scenario
01:38:08.400 --> 01:38:08.860
let's
01:38:08.860 --> 01:38:08.960
say
01:38:08.960 --> 01:38:09.220
user
01:38:09.220 --> 01:38:09.420
hits
01:38:10.420 --> 01:38:10.940
slash
01:38:10.940 --> 01:38:11.640
categories
01:38:12.560 --> 01:38:13.080
and
01:38:13.080 --> 01:38:13.260
he
01:38:13.260 --> 01:38:13.460
don't
01:38:13.460 --> 01:38:13.640
care
01:38:13.640 --> 01:38:13.740
about
01:38:15.600 --> 01:38:16.120
what
01:38:16.120 --> 01:38:16.660
about
01:38:16.660 --> 01:38:17.040
the
01:38:17.040 --> 01:38:17.260
categories
01:38:17.260 --> 01:38:17.620
that are
01:38:17.620 --> 01:38:17.780
already
01:38:17.780 --> 01:38:18.000
present
01:38:18.000 --> 01:38:18.220
in
01:38:18.220 --> 01:38:18.460
database
01:38:18.460 --> 01:38:18.740
and
01:38:18.740 --> 01:38:19.060
all
01:38:19.060 --> 01:38:19.340
he
01:38:19.340 --> 01:38:19.500
just
01:38:19.500 --> 01:38:19.600
wanted
01:38:19.600 --> 01:38:19.860
to
01:38:19.860 --> 01:38:19.980
get
01:38:19.980 --> 01:38:20.240
the
01:38:20.240 --> 01:38:20.560
categories
01:38:20.560 --> 01:38:21.400
so
01:38:21.400 --> 01:38:21.660
if
01:38:21.660 --> 01:38:21.840
you
01:38:21.840 --> 01:38:22.020
see
01:38:22.020 --> 01:38:22.160
you
01:38:22.160 --> 01:38:22.260
over
01:38:22.260 --> 01:38:22.540
here
01:38:22.540 --> 01:38:22.900
we have
01:38:22.900 --> 01:38:23.420
implemented
01:38:23.420 --> 01:38:23.760
get
01:38:23.760 --> 01:38:23.980
based
01:38:25.740 --> 01:38:26.260
description
01:38:27.080 --> 01:38:27.600
so
01:38:27.600 --> 01:38:28.480
it
01:38:29.100 --> 01:38:29.620
already
01:38:29.620 --> 01:38:30.080
should be
01:38:32.920 --> 01:38:33.480
I mean
01:38:33.500 --> 01:38:34.220
get request
01:38:35.340 --> 01:38:36.000
and then
01:38:36.000 --> 01:38:36.480
we are providing
01:38:36.480 --> 01:38:36.840
the
01:38:36.840 --> 01:38:37.200
description
01:38:37.200 --> 01:38:38.020
what
01:38:39.100 --> 01:38:39.780
exactly
01:38:39.780 --> 01:38:39.900
this
01:38:40.760 --> 01:38:41.300
API
01:38:42.860 --> 01:38:43.040
API
01:38:43.040 --> 01:38:43.740
route
01:38:43.740 --> 01:38:44.480
does
01:38:44.480 --> 01:38:45.680
basically
01:38:45.680 --> 01:38:47.020
it helps
01:38:47.020 --> 01:38:47.320
us
01:38:47.320 --> 01:38:47.520
to
01:38:47.520 --> 01:38:47.700
get
01:38:47.700 --> 01:38:48.300
the
01:38:48.300 --> 01:38:48.680
categories
01:38:48.680 --> 01:38:49.280
so
01:38:49.280 --> 01:38:49.820
this
01:38:49.820 --> 01:38:50.180
display
01:38:50.180 --> 01:38:50.600
name
01:38:50.600 --> 01:38:51.400
is
01:38:51.400 --> 01:38:51.900
described
01:38:51.900 --> 01:38:52.220
under
01:38:53.660 --> 01:38:54.580
our
01:38:54.580 --> 01:38:54.860
Anypoint
01:38:54.860 --> 01:38:55.380
platform
01:38:55.380 --> 01:38:55.740
basically
01:38:56.300 --> 01:38:56.720
once
01:38:56.720 --> 01:38:57.000
we
01:38:57.000 --> 01:38:57.580
deployed
01:38:57.580 --> 01:38:58.320
or
01:38:58.320 --> 01:38:58.580
once
01:38:58.580 --> 01:38:58.720
we
01:38:58.720 --> 01:38:58.900
run
01:38:58.900 --> 01:38:59.400
this
01:38:59.400 --> 01:39:00.200
using
01:39:01.020 --> 01:39:01.560
Anypoint
01:39:01.560 --> 01:39:01.880
Studio
01:39:01.880 --> 01:39:02.160
we'll
01:39:02.160 --> 01:39:02.300
be
01:39:02.300 --> 01:39:02.520
getting
01:39:02.520 --> 01:39:02.860
much
01:39:02.860 --> 01:39:03.320
more
01:39:03.500 --> 01:39:04.480
understanding
01:39:04.480 --> 01:39:04.800
over
01:39:04.800 --> 01:39:05.140
what
01:39:05.140 --> 01:39:05.480
this
01:39:05.480 --> 01:39:05.700
display
01:39:05.700 --> 01:39:05.900
name
01:39:05.900 --> 01:39:06.140
and
01:39:06.140 --> 01:39:06.340
what
01:39:06.340 --> 01:39:06.640
this
01:39:06.640 --> 01:39:06.780
query
01:39:06.780 --> 01:39:07.140
parameters
01:39:07.140 --> 01:39:07.800
are
01:39:08.460 --> 01:39:08.840
but
01:39:08.840 --> 01:39:09.620
like
01:39:09.620 --> 01:39:09.820
right
01:39:09.820 --> 01:39:10.120
now
01:39:10.120 --> 01:39:10.400
the
01:39:10.400 --> 01:39:10.540
query
01:39:10.540 --> 01:39:10.960
parameters
01:39:10.960 --> 01:39:11.220
are
01:39:11.220 --> 01:39:11.260
like
01:39:12.220 --> 01:39:12.860
let's
01:39:12.860 --> 01:39:13.160
say
01:39:13.160 --> 01:39:13.740
for
01:39:13.740 --> 01:39:14.040
this
01:39:14.040 --> 01:39:14.360
URL
01:39:17.440 --> 01:39:18.080
if
01:39:28.640 --> 01:39:29.280
you
01:39:33.500 --> 01:39:34.020
get
01:39:34.020 --> 01:39:34.380
search
01:39:34.380 --> 01:39:34.900
parameters
01:39:34.900 --> 01:39:35.600
right
01:39:35.600 --> 01:39:36.080
so
01:39:36.080 --> 01:39:36.600
the search
01:39:36.600 --> 01:39:37.320
search key
01:39:37.320 --> 01:39:37.760
and then
01:39:37.760 --> 01:39:37.960
search
01:39:37.960 --> 01:39:38.420
value
01:39:40.000 --> 01:39:40.600
even
01:39:40.600 --> 01:39:41.140
though
01:39:41.140 --> 01:39:41.540
I mean
01:39:41.540 --> 01:39:41.860
YouTube
01:39:41.860 --> 01:39:42.180
works
01:39:42.180 --> 01:39:42.480
I mean
01:39:42.480 --> 01:39:42.740
the
01:39:42.740 --> 01:39:42.980
URL
01:39:42.980 --> 01:39:43.620
works
01:39:44.140 --> 01:39:44.840
let's say
01:39:44.840 --> 01:39:45.240
if we
01:39:45.240 --> 01:39:45.420
don't
01:39:45.420 --> 01:39:45.900
pass any
01:39:45.900 --> 01:39:46.120
these
01:39:46.120 --> 01:39:46.600
parameters
01:39:46.600 --> 01:39:47.280
let's
01:39:47.280 --> 01:39:47.820
say
01:39:48.380 --> 01:39:49.120
we just
01:39:49.120 --> 01:39:49.520
did not
01:39:49.520 --> 01:39:49.920
pass any
01:39:49.920 --> 01:39:50.240
value
01:39:50.240 --> 01:39:51.000
over here
01:39:51.000 --> 01:39:51.440
so
01:39:51.440 --> 01:39:51.740
it's
01:39:51.740 --> 01:39:51.820
just
01:39:52.900 --> 01:39:53.680
there is
01:39:53.680 --> 01:39:53.860
a
01:39:54.540 --> 01:39:55.140
fallback
01:39:55.140 --> 01:39:55.820
page
01:39:55.820 --> 01:39:56.200
for this
01:39:56.200 --> 01:39:56.440
to
01:39:56.440 --> 01:39:56.640
handle
01:39:56.640 --> 01:39:56.940
this
01:39:56.940 --> 01:39:57.200
request
01:39:57.200 --> 01:39:58.060
so that
01:39:58.060 --> 01:39:58.720
these are
01:39:58.720 --> 01:39:58.900
called
01:39:58.900 --> 01:39:59.420
as
01:39:59.420 --> 01:39:59.620
query
01:39:59.620 --> 01:40:00.560
parameters
01:40:00.560 --> 01:40:01.340
inside
01:40:01.340 --> 01:40:01.780
API
01:40:01.780 --> 01:40:02.360
languages
01:40:02.360 --> 01:40:03.100
basically
01:40:03.500 --> 01:40:04.060
so
01:40:04.060 --> 01:40:04.520
these
01:40:04.520 --> 01:40:04.720
query
01:40:04.720 --> 01:40:05.160
parameters
01:40:05.160 --> 01:40:05.440
are
01:40:05.440 --> 01:40:05.980
like
01:40:05.980 --> 01:40:06.300
a
01:40:06.300 --> 01:40:06.580
string
01:40:06.580 --> 01:40:07.640
I mean
01:40:07.640 --> 01:40:08.540
we'll be describing
01:40:08.540 --> 01:40:08.980
a query
01:40:08.980 --> 01:40:09.340
parameters
01:40:09.340 --> 01:40:09.920
over here
01:40:09.920 --> 01:40:10.260
so
01:40:10.260 --> 01:40:11.000
let's say
01:40:11.000 --> 01:40:11.480
for
01:40:11.480 --> 01:40:11.680
this
01:40:11.680 --> 01:40:11.980
specific
01:40:11.980 --> 01:40:12.480
implementation
01:40:12.480 --> 01:40:13.400
we have
01:40:13.400 --> 01:40:13.760
this
01:40:13.760 --> 01:40:14.080
name
01:40:14.080 --> 01:40:14.900
as one
01:40:14.900 --> 01:40:15.240
of the
01:40:15.240 --> 01:40:15.360
query
01:40:15.360 --> 01:40:15.840
parameter
01:40:15.840 --> 01:40:16.420
and
01:40:16.420 --> 01:40:17.560
it is
01:40:17.560 --> 01:40:17.960
optional
01:40:17.960 --> 01:40:18.060
thing
01:40:18.860 --> 01:40:19.440
let's say
01:40:19.440 --> 01:40:19.620
for
01:40:19.620 --> 01:40:19.960
example
01:40:19.960 --> 01:40:20.400
YouTube
01:40:20.940 --> 01:40:21.580
we have
01:40:21.580 --> 01:40:22.060
this
01:40:22.060 --> 01:40:22.200
query
01:40:22.200 --> 01:40:22.600
parameter
01:40:24.560 --> 01:40:25.240
as
01:40:25.980 --> 01:40:26.460
chalk
01:40:26.460 --> 01:40:27.040
as
01:40:27.040 --> 01:40:27.220
I mean
01:40:27.220 --> 01:40:27.480
the
01:40:27.480 --> 01:40:27.720
search
01:40:27.720 --> 01:40:27.940
query
01:40:27.940 --> 01:40:28.320
as
01:40:28.320 --> 01:40:28.540
query
01:40:28.540 --> 01:40:29.080
parameter
01:40:29.080 --> 01:40:30.160
if we
01:40:30.160 --> 01:40:30.440
want
01:40:30.440 --> 01:40:30.900
like you
01:40:30.900 --> 01:40:31.140
know
01:40:31.140 --> 01:40:31.520
replicate
01:40:31.520 --> 01:40:31.860
the
01:40:31.860 --> 01:40:32.120
same
01:40:32.120 --> 01:40:32.660
thing
01:40:32.660 --> 01:40:33.100
inside
01:40:33.100 --> 01:40:33.480
R
01:40:33.480 --> 01:40:33.880
specific
01:40:33.880 --> 01:40:34.380
implementation
01:40:34.380 --> 01:40:35.060
the
01:40:35.060 --> 01:40:35.380
name
01:40:35.380 --> 01:40:36.140
can be
01:40:36.140 --> 01:40:36.620
replaced by
01:40:36.620 --> 01:40:37.180
search query
01:40:37.180 --> 01:40:37.940
so this is
01:40:37.940 --> 01:40:38.120
like
01:40:38.120 --> 01:40:38.420
read-only
01:40:38.420 --> 01:40:38.940
editor
01:40:38.940 --> 01:40:39.840
but
01:40:39.840 --> 01:40:40.300
yeah
01:40:40.300 --> 01:40:40.420
name
01:40:40.420 --> 01:40:40.840
can be
01:40:40.840 --> 01:40:41.460
replaced by
01:40:41.460 --> 01:40:41.860
search
01:40:41.860 --> 01:40:42.300
query
01:40:42.300 --> 01:40:42.940
you got
01:40:42.940 --> 01:40:43.300
right
01:40:43.300 --> 01:40:43.900
so
01:40:43.900 --> 01:40:44.740
how that
01:40:44.740 --> 01:40:45.180
how it
01:40:45.180 --> 01:40:45.400
works
01:40:45.400 --> 01:40:45.940
basically
01:40:45.940 --> 01:40:46.640
you'll
01:40:46.640 --> 01:40:46.860
be
01:40:46.860 --> 01:40:47.140
decide
01:40:47.140 --> 01:40:47.480
I mean
01:40:47.480 --> 01:40:47.740
you'll
01:40:47.740 --> 01:40:47.920
be
01:40:47.920 --> 01:40:48.160
designing
01:40:48.160 --> 01:40:48.580
these
01:40:48.580 --> 01:40:48.900
YouTube
01:40:48.900 --> 01:40:49.720
implementations
01:40:49.720 --> 01:40:50.060
with the
01:40:50.060 --> 01:40:50.200
help of
01:40:51.500 --> 01:40:51.740
this
01:40:51.740 --> 01:40:51.980
Mule
01:40:51.980 --> 01:40:52.820
software
01:40:52.820 --> 01:40:53.480
queries
01:40:53.480 --> 01:40:54.060
languages
01:40:54.060 --> 01:40:54.460
actually
01:40:54.460 --> 01:40:55.180
and then
01:40:55.180 --> 01:40:55.560
what are
01:40:55.560 --> 01:40:55.720
the
01:40:55.720 --> 01:40:56.020
responses
01:40:56.020 --> 01:40:56.300
that you
01:40:56.300 --> 01:40:56.700
wanted to
01:40:56.700 --> 01:40:57.000
provide
01:40:57.640 --> 01:40:58.460
let's say
01:40:58.460 --> 01:40:59.020
here
01:40:59.020 --> 01:40:59.780
I did not
01:40:59.780 --> 01:40:59.980
provide
01:40:59.980 --> 01:41:00.120
any
01:41:00.820 --> 01:41:01.240
response
01:41:01.240 --> 01:41:01.660
over here
01:41:01.660 --> 01:41:02.140
and
01:41:02.140 --> 01:41:02.680
it just
01:41:02.680 --> 01:41:03.460
fall back to
01:41:03.480 --> 01:41:04.360
no results found
01:41:04.360 --> 01:41:04.900
page
01:41:04.900 --> 01:41:05.400
but
01:41:06.980 --> 01:41:07.900
let's say
01:41:07.900 --> 01:41:08.220
if I
01:41:08.220 --> 01:41:08.760
have provided
01:41:09.920 --> 01:41:10.620
like
01:41:10.620 --> 01:41:11.240
write
01:41:11.240 --> 01:41:11.780
query
01:41:13.140 --> 01:41:13.920
if I
01:41:13.920 --> 01:41:14.200
go to
01:41:14.200 --> 01:41:14.580
the developer
01:41:14.580 --> 01:41:15.120
tools
01:41:15.120 --> 01:41:15.600
again
01:41:15.600 --> 01:41:16.300
you see the
01:41:16.300 --> 01:41:16.720
status
01:41:16.720 --> 01:41:17.000
like
01:41:17.000 --> 01:41:17.320
200
01:41:17.320 --> 01:41:17.780
status
01:41:18.280 --> 01:41:19.000
how exactly
01:41:19.000 --> 01:41:19.480
is this
01:41:19.480 --> 01:41:20.000
implemented
01:41:20.000 --> 01:41:20.860
it with the
01:41:20.860 --> 01:41:21.280
help of
01:41:21.280 --> 01:41:21.480
this one
01:41:23.160 --> 01:41:23.800
the response
01:41:23.800 --> 01:41:24.100
status
01:41:24.100 --> 01:41:24.880
200
01:41:25.560 --> 01:41:25.920
so
01:41:25.920 --> 01:41:26.580
basically
01:41:27.460 --> 01:41:27.480
in
01:41:28.960 --> 01:41:30.220
you might
01:41:30.220 --> 01:41:31.540
you might
01:41:31.540 --> 01:41:32.240
know about
01:41:32.240 --> 01:41:32.820
404
01:41:32.820 --> 01:41:33.100
status
01:41:33.100 --> 01:41:34.240
page not found
01:41:34.240 --> 01:41:34.880
while
01:41:34.880 --> 01:41:35.440
navigating
01:41:35.440 --> 01:41:35.980
in the
01:41:35.980 --> 01:41:36.320
internet
01:41:37.260 --> 01:41:37.880
that is
01:41:38.540 --> 01:41:39.060
globally
01:41:39.060 --> 01:41:39.540
known
01:41:39.540 --> 01:41:40.040
a response
01:41:40.040 --> 01:41:40.400
code
01:41:40.400 --> 01:41:41.140
apart from
01:41:41.140 --> 01:41:41.400
those
01:41:41.400 --> 01:41:41.760
response
01:41:41.760 --> 01:41:42.120
codes
01:41:42.620 --> 01:41:43.120
we have
01:41:43.120 --> 01:41:43.620
lot of
01:41:43.620 --> 01:41:43.900
response
01:41:43.900 --> 01:41:44.060
codes
01:41:45.360 --> 01:41:46.400
couple of
01:41:46.400 --> 01:41:46.700
response
01:41:46.700 --> 01:41:47.020
codes are
01:41:48.720 --> 01:41:49.460
2x6
01:41:53.340 --> 01:41:54.080
3x6
01:41:57.660 --> 01:41:58.460
these are
01:41:58.460 --> 01:41:59.300
prerequisite
01:42:01.180 --> 01:42:01.920
okay
01:42:01.920 --> 01:42:02.760
so
01:42:02.760 --> 01:42:03.620
2x6
01:42:03.620 --> 01:42:04.080
series
01:42:04.080 --> 01:42:05.280
it corresponds
01:42:05.280 --> 01:42:05.720
to the
01:42:05.720 --> 01:42:06.380
success
01:42:06.380 --> 01:42:07.180
responses
01:42:07.180 --> 01:42:08.240
so basically
01:42:08.240 --> 01:42:08.900
whenever
01:42:08.900 --> 01:42:10.000
let's say
01:42:10.000 --> 01:42:10.380
you hit
01:42:10.380 --> 01:42:10.820
an API
01:42:10.820 --> 01:42:11.700
and
01:42:11.700 --> 01:42:12.020
you got
01:42:12.020 --> 01:42:12.600
a response
01:42:13.860 --> 01:42:14.440
so
01:42:14.440 --> 01:42:15.500
you should
01:42:15.500 --> 01:42:15.640
tell
01:42:16.460 --> 01:42:17.020
caller
01:42:17.020 --> 01:42:17.880
the person
01:42:17.880 --> 01:42:18.380
who calls
01:42:18.380 --> 01:42:18.920
this API
01:42:18.920 --> 01:42:19.320
that
01:42:20.040 --> 01:42:20.760
everything is
01:42:20.760 --> 01:42:20.980
done
01:42:21.600 --> 01:42:22.180
and
01:42:22.180 --> 01:42:22.600
you got
01:42:22.600 --> 01:42:23.220
a response
01:42:23.220 --> 01:42:24.500
so that
01:42:24.500 --> 01:42:25.080
is the
01:42:25.080 --> 01:42:25.820
specific response
01:42:25.820 --> 01:42:26.200
code that
01:42:26.200 --> 01:42:26.420
we're
01:42:26.420 --> 01:42:26.720
going to be
01:42:26.720 --> 01:42:27.060
delivering
01:42:27.060 --> 01:42:27.760
so
01:42:27.760 --> 01:42:28.260
since this
01:42:28.260 --> 01:42:28.520
is a
01:42:28.520 --> 01:42:29.400
get request
01:42:29.400 --> 01:42:30.500
mostly
01:42:30.500 --> 01:42:30.980
for most
01:42:30.980 --> 01:42:31.240
of the
01:42:31.240 --> 01:42:31.660
get request
01:42:31.660 --> 01:42:32.200
it will be
01:42:32.760 --> 01:42:33.460
200
01:42:33.460 --> 01:42:34.440
response
01:42:34.440 --> 01:42:34.740
code
01:42:34.740 --> 01:42:35.320
let's say
01:42:35.320 --> 01:42:36.160
for post request
01:42:36.920 --> 01:42:37.420
we have
01:42:37.420 --> 01:42:38.140
this 201
01:42:38.140 --> 01:42:39.200
response code
01:42:39.200 --> 01:42:39.980
201
01:42:39.980 --> 01:42:40.840
stands for
01:42:40.840 --> 01:42:41.500
our
01:42:41.500 --> 01:42:41.780
resource
01:42:41.780 --> 01:42:42.160
created
01:42:42.840 --> 01:42:43.480
basically
01:42:48.900 --> 01:42:49.540
so
01:42:49.540 --> 01:42:49.920
it's like
01:42:49.920 --> 01:42:50.360
one of the
01:42:50.360 --> 01:42:50.760
it is also
01:42:50.760 --> 01:42:51.100
one of the
01:42:51.100 --> 01:42:51.420
positive
01:42:51.420 --> 01:42:52.100
response code
01:42:52.100 --> 01:42:53.000
all the
01:42:53.000 --> 01:42:53.300
response
01:42:53.300 --> 01:42:53.720
codes that
01:42:53.720 --> 01:42:54.020
are
01:42:54.020 --> 01:42:54.480
present in
01:42:54.480 --> 01:42:55.040
2x6
01:42:55.040 --> 01:42:55.960
2x6
01:42:55.960 --> 01:42:56.440
range
01:42:56.440 --> 01:42:57.060
they're
01:42:57.060 --> 01:42:57.240
just
01:42:57.240 --> 01:42:57.580
positive
01:42:57.580 --> 01:42:58.220
response code
01:43:00.820 --> 01:43:01.460
it
01:43:02.940 --> 01:43:04.040
we can have
01:43:10.460 --> 01:43:11.100
so
01:43:11.100 --> 01:43:11.780
these are
01:43:11.780 --> 01:43:12.400
history status
01:43:12.400 --> 01:43:12.740
code
01:43:12.740 --> 01:43:13.300
as I'm
01:43:13.300 --> 01:43:13.460
told
01:43:13.460 --> 01:43:14.020
already
01:43:14.020 --> 01:43:14.660
like
01:43:14.660 --> 01:43:15.260
200 is
01:43:16.340 --> 01:43:16.980
like
01:43:18.120 --> 01:43:18.760
created
01:43:18.760 --> 01:43:19.420
the resource
01:43:19.420 --> 01:43:19.720
created
01:43:19.720 --> 01:43:20.160
one
01:43:20.160 --> 01:43:20.840
200 is
01:43:20.840 --> 01:43:21.420
okay one
01:43:21.420 --> 01:43:22.000
okay in
01:43:22.000 --> 01:43:22.720
this sense
01:43:23.440 --> 01:43:24.360
it doesn't
01:43:24.360 --> 01:43:24.800
have any
01:43:24.800 --> 01:43:25.000
meaning
01:43:25.000 --> 01:43:26.540
with it
01:43:26.540 --> 01:43:27.420
for 200
01:43:27.420 --> 01:43:27.820
response
01:43:27.820 --> 01:43:28.000
codes
01:43:28.000 --> 01:43:28.360
we should
01:43:28.360 --> 01:43:28.700
always
01:43:28.700 --> 01:43:29.020
be looking
01:43:29.020 --> 01:43:29.340
at
01:43:29.340 --> 01:43:30.080
the body
01:43:30.080 --> 01:43:30.780
what
01:43:30.780 --> 01:43:31.220
exactly
01:43:31.220 --> 01:43:31.500
is
01:43:31.500 --> 01:43:31.740
written
01:43:31.740 --> 01:43:32.340
for us
01:43:32.760 --> 01:43:33.420
in our
01:43:33.420 --> 01:43:34.020
scenario
01:43:34.020 --> 01:43:34.820
let's say
01:43:34.820 --> 01:43:35.280
we have
01:43:35.280 --> 01:43:35.580
designed
01:43:35.580 --> 01:43:35.820
our
01:43:35.820 --> 01:43:36.280
application
01:43:36.280 --> 01:43:37.100
to provide
01:43:37.100 --> 01:43:37.320
a
01:43:37.320 --> 01:43:37.940
response
01:43:37.940 --> 01:43:38.520
for a
01:43:38.520 --> 01:43:39.060
get request
01:43:39.720 --> 01:43:40.280
we have
01:43:40.280 --> 01:43:40.680
designed
01:43:40.680 --> 01:43:41.060
our
01:43:41.060 --> 01:43:41.460
application
01:43:41.460 --> 01:43:41.900
in such
01:43:41.900 --> 01:43:42.020
a
01:43:42.020 --> 01:43:42.100
way
01:43:42.100 --> 01:43:42.200
that
01:43:43.300 --> 01:43:44.020
let's
01:43:44.020 --> 01:43:44.400
say
01:43:44.400 --> 01:43:45.220
for
01:43:45.220 --> 01:43:45.500
this
01:43:45.500 --> 01:43:45.840
specific
01:43:45.840 --> 01:43:46.180
endpoint
01:43:46.180 --> 01:43:46.800
it is
01:43:46.800 --> 01:43:47.180
categories
01:43:47.180 --> 01:43:47.700
response
01:43:47.700 --> 01:43:48.140
code
01:43:48.140 --> 01:43:48.720
so
01:43:48.720 --> 01:43:48.920
we'll
01:43:48.920 --> 01:43:49.100
be
01:43:49.100 --> 01:43:49.300
going
01:43:49.300 --> 01:43:49.600
over
01:43:49.600 --> 01:43:50.100
here
01:43:50.100 --> 01:43:50.480
and
01:43:50.480 --> 01:43:50.640
hitting
01:43:50.640 --> 01:43:50.900
an
01:43:50.900 --> 01:43:51.140
API
01:43:51.140 --> 01:43:51.840
and
01:43:51.840 --> 01:43:52.040
we'll
01:43:52.040 --> 01:43:52.200
be
01:43:52.200 --> 01:43:52.280
getting
01:43:53.460 --> 01:43:54.180
category
01:43:54.180 --> 01:43:54.760
response
01:43:54.760 --> 01:43:55.940
so
01:43:55.940 --> 01:43:56.240
the
01:43:56.240 --> 01:43:56.440
category
01:43:56.440 --> 01:43:56.920
response
01:43:56.920 --> 01:43:57.580
would be
01:43:57.580 --> 01:43:58.120
something
01:44:02.760 --> 01:44:03.100
so
01:44:03.100 --> 01:44:03.300
this
01:44:03.300 --> 01:44:03.460
is
01:44:03.460 --> 01:44:03.620
the
01:44:03.620 --> 01:44:03.840
unique
01:44:03.840 --> 01:44:04.380
identifier
01:44:04.380 --> 01:44:05.080
what
01:44:05.080 --> 01:44:05.340
is
01:44:05.340 --> 01:44:05.600
the
01:44:05.600 --> 01:44:05.800
name
01:44:05.800 --> 01:44:06.040
of
01:44:06.040 --> 01:44:06.240
this
01:44:06.240 --> 01:44:06.620
category
01:44:06.620 --> 01:44:06.820
and
01:44:06.820 --> 01:44:06.960
what
01:44:06.960 --> 01:44:07.140
is
01:44:07.140 --> 01:44:07.300
the
01:44:07.300 --> 01:44:07.600
description
01:44:07.600 --> 01:44:07.820
of
01:44:07.820 --> 01:44:07.980
this
01:44:07.980 --> 01:44:08.200
category
01:44:08.200 --> 01:44:08.380
so
01:44:08.380 --> 01:44:08.540
this
01:44:08.540 --> 01:44:08.700
is
01:44:08.700 --> 01:44:08.840
the
01:44:08.840 --> 01:44:09.300
response
01:44:09.300 --> 01:44:10.200
but
01:44:10.200 --> 01:44:10.480
if
01:44:10.480 --> 01:44:10.600
you
01:44:10.600 --> 01:44:10.720
can
01:44:10.720 --> 01:44:10.960
see
01:44:10.960 --> 01:44:11.160
over
01:44:11.160 --> 01:44:11.420
here
01:44:11.420 --> 01:44:11.780
this
01:44:11.780 --> 01:44:12.180
response
01:44:12.180 --> 01:44:12.280
is
01:44:12.960 --> 01:44:13.480
described
01:44:13.480 --> 01:44:13.660
in
01:44:13.660 --> 01:44:13.960
terms
01:44:13.960 --> 01:44:14.320
of
01:44:14.320 --> 01:44:14.520
YAML
01:44:15.120 --> 01:44:15.640
but
01:44:15.640 --> 01:44:16.180
typically
01:44:16.180 --> 01:44:16.640
this
01:44:16.640 --> 01:44:16.820
is
01:44:16.820 --> 01:44:17.020
not
01:44:17.020 --> 01:44:17.180
the
01:44:17.180 --> 01:44:17.240
way
01:44:18.740 --> 01:44:19.260
each
01:44:19.260 --> 01:44:19.460
and
01:44:19.460 --> 01:44:19.580
every
01:44:19.580 --> 01:44:19.980
response
01:44:19.980 --> 01:44:20.160
will
01:44:20.160 --> 01:44:20.280
be
01:44:20.280 --> 01:44:20.460
on
01:44:20.460 --> 01:44:20.640
JSON
01:44:20.640 --> 01:44:21.000
format
01:44:21.000 --> 01:44:21.500
only
01:44:21.500 --> 01:44:21.920
at
01:44:22.480 --> 01:44:23.000
least
01:44:23.560 --> 01:44:24.040
open
01:44:24.040 --> 01:44:24.260
API
01:44:24.260 --> 01:44:24.800
specifications
01:44:24.800 --> 01:44:25.060
are
01:44:25.060 --> 01:44:25.440
concerned
01:44:25.440 --> 01:44:26.140
but
01:44:26.140 --> 01:44:26.640
right now
01:44:26.640 --> 01:44:27.340
for our
01:44:27.340 --> 01:44:27.640
Mulesoft
01:44:27.640 --> 01:44:28.480
implementations
01:44:28.480 --> 01:44:29.080
we are
01:44:29.080 --> 01:44:29.600
forward
01:44:29.600 --> 01:44:30.040
with the
01:44:30.040 --> 01:44:30.200
YAML
01:44:30.200 --> 01:44:30.580
based
01:44:30.580 --> 01:44:30.960
approaches
01:44:30.960 --> 01:44:31.560
like
01:44:31.560 --> 01:44:31.880
all
01:44:31.880 --> 01:44:33.000
the
01:44:33.000 --> 01:44:33.400
retail
01:44:33.960 --> 01:44:34.600
I mean
01:44:34.600 --> 01:44:35.440
the
01:44:35.440 --> 01:44:35.580
root
01:44:35.580 --> 01:44:36.180
implementations
01:44:36.180 --> 01:44:36.500
we have
01:44:36.500 --> 01:44:36.520
this
01:44:37.140 --> 01:44:37.620
but
01:44:37.620 --> 01:44:38.280
if you
01:44:38.280 --> 01:44:38.500
see
01:44:38.500 --> 01:44:38.780
here
01:44:38.780 --> 01:44:39.180
body
01:44:39.180 --> 01:44:39.700
type
01:44:39.700 --> 01:44:40.360
it is
01:44:40.360 --> 01:44:40.840
application
01:44:40.840 --> 01:44:41.240
.JSON
01:44:42.280 --> 01:44:42.680
I've
01:44:42.680 --> 01:44:42.880
told
01:44:42.880 --> 01:44:43.180
right
01:44:43.180 --> 01:44:43.600
all
01:44:43.600 --> 01:44:43.640
the
01:44:45.000 --> 01:44:45.260
kind
01:44:45.260 --> 01:44:45.560
of
01:44:45.560 --> 01:44:46.240
implementations
01:44:46.240 --> 01:44:46.540
you
01:44:46.540 --> 01:44:46.920
have
01:44:46.920 --> 01:44:47.540
it will
01:44:47.540 --> 01:44:47.700
be
01:44:47.700 --> 01:44:47.900
on
01:44:47.900 --> 01:44:48.140
JSON
01:44:48.140 --> 01:44:48.640
itself
01:44:48.640 --> 01:44:49.000
not
01:44:49.000 --> 01:44:49.340
the
01:44:49.340 --> 01:44:49.920
YAML
01:44:49.920 --> 01:44:50.460
but
01:44:50.460 --> 01:44:50.920
we'll
01:44:50.920 --> 01:44:51.140
be
01:44:51.140 --> 01:44:51.480
defining
01:44:51.480 --> 01:44:52.260
everything
01:44:52.260 --> 01:44:53.060
in
01:44:53.060 --> 01:44:53.360
JSON
01:44:53.360 --> 01:44:53.960
format
01:44:53.960 --> 01:44:54.740
sorry
01:44:54.740 --> 01:44:55.120
in
01:44:55.120 --> 01:44:55.360
YAML
01:44:55.360 --> 01:44:55.800
format
01:44:55.800 --> 01:44:56.460
so that
01:44:56.460 --> 01:44:56.920
we can
01:44:56.920 --> 01:44:57.440
define
01:44:57.440 --> 01:44:57.800
the
01:44:57.800 --> 01:44:58.120
responses
01:44:58.120 --> 01:44:58.560
that are
01:44:58.560 --> 01:44:58.840
already
01:44:58.840 --> 01:44:59.580
that will
01:44:59.580 --> 01:44:59.640
be
01:45:00.640 --> 01:45:02.740
you know
01:45:02.740 --> 01:45:03.040
served
01:45:03.040 --> 01:45:03.480
by
01:45:03.480 --> 01:45:03.900
the
01:45:03.900 --> 01:45:04.540
API request
01:45:04.540 --> 01:45:05.220
so you
01:45:05.220 --> 01:45:05.540
got the
01:45:05.540 --> 01:45:05.820
point right
01:45:05.820 --> 01:45:06.220
so the
01:45:06.220 --> 01:45:06.520
response
01:45:06.520 --> 01:45:07.140
will be
01:45:07.140 --> 01:45:07.480
inside
01:45:08.120 --> 01:45:08.580
I mean
01:45:08.580 --> 01:45:08.780
the
01:45:08.780 --> 01:45:08.960
response
01:45:08.960 --> 01:45:09.300
will be
01:45:09.300 --> 01:45:09.880
of
01:45:09.880 --> 01:45:10.280
JSON
01:45:10.280 --> 01:45:10.780
format
01:45:10.780 --> 01:45:11.640
but the
01:45:11.640 --> 01:45:12.160
specifications
01:45:12.160 --> 01:45:12.760
but
01:45:12.760 --> 01:45:13.120
what
01:45:13.120 --> 01:45:13.420
we
01:45:13.420 --> 01:45:13.900
provide
01:45:13.900 --> 01:45:14.500
to
01:45:14.500 --> 01:45:14.660
serve
01:45:14.660 --> 01:45:14.880
that
01:45:14.880 --> 01:45:15.280
responses
01:45:15.280 --> 01:45:15.640
will be
01:45:15.640 --> 01:45:15.760
on
01:45:15.760 --> 01:45:15.960
YAML
01:45:15.960 --> 01:45:16.360
format
01:45:16.360 --> 01:45:16.440
yeah
01:45:17.580 --> 01:45:18.240
so
01:45:18.240 --> 01:45:18.860
that's
01:45:18.860 --> 01:45:19.060
the
01:45:19.060 --> 01:45:19.740
way
01:45:19.740 --> 01:45:20.340
works
01:45:20.340 --> 01:45:20.920
then
01:45:20.920 --> 01:45:21.520
yeah
01:45:22.620 --> 01:45:23.280
so
01:45:23.280 --> 01:45:23.900
we'll
01:45:23.900 --> 01:45:24.060
be
01:45:24.060 --> 01:45:24.260
defining
01:45:24.260 --> 01:45:24.480
the
01:45:24.480 --> 01:45:25.020
response
01:45:25.020 --> 01:45:25.920
and
01:45:25.920 --> 01:45:26.220
we'll
01:45:26.220 --> 01:45:26.620
be providing
01:45:26.620 --> 01:45:26.680
the
01:45:27.360 --> 01:45:27.800
type
01:45:27.800 --> 01:45:28.000
of
01:45:28.000 --> 01:45:28.160
the
01:45:28.160 --> 01:45:28.700
response
01:45:28.840 --> 01:45:29.960
so basically
01:45:29.960 --> 01:45:31.020
there is
01:45:31.020 --> 01:45:31.480
a hard
01:45:31.480 --> 01:45:31.960
rule
01:45:32.820 --> 01:45:33.460
that
01:45:33.460 --> 01:45:34.040
this
01:45:34.040 --> 01:45:34.220
type
01:45:34.220 --> 01:45:35.640
should be
01:45:35.640 --> 01:45:36.020
already
01:45:36.020 --> 01:45:36.420
defined
01:45:36.420 --> 01:45:36.660
type
01:45:36.660 --> 01:45:37.080
in this
01:45:37.080 --> 01:45:37.480
file
01:45:37.480 --> 01:45:38.400
let's say
01:45:38.400 --> 01:45:38.860
we have
01:45:38.860 --> 01:45:39.160
category
01:45:39.160 --> 01:45:39.480
collection
01:45:39.480 --> 01:45:39.880
response
01:45:39.880 --> 01:45:40.740
right
01:45:40.740 --> 01:45:41.160
if you
01:45:41.160 --> 01:45:41.460
go
01:45:41.460 --> 01:45:41.920
here
01:45:42.600 --> 01:45:43.180
we have
01:45:43.180 --> 01:45:43.760
defined
01:45:44.520 --> 01:45:45.160
how
01:45:45.160 --> 01:45:45.780
a category
01:45:45.780 --> 01:45:46.120
collection
01:45:46.120 --> 01:45:46.440
response
01:45:46.440 --> 01:45:47.160
should be
01:45:47.160 --> 01:45:47.440
with
01:45:47.440 --> 01:45:47.840
the help
01:45:48.960 --> 01:45:49.600
properties
01:45:49.600 --> 01:45:49.920
called
01:45:49.920 --> 01:45:50.340
categories
01:45:50.340 --> 01:45:50.760
itself
01:45:50.760 --> 01:45:51.420
if you
01:45:51.420 --> 01:45:51.580
go
01:45:51.580 --> 01:45:51.840
here
01:45:51.840 --> 01:45:52.200
in the
01:45:52.200 --> 01:45:52.920
taxonomy
01:45:53.900 --> 01:45:54.680
we have
01:45:54.680 --> 01:45:55.120
this
01:45:55.120 --> 01:45:55.540
taxonomy
01:45:55.540 --> 01:45:55.880
defined
01:45:55.880 --> 01:45:56.260
already
01:45:56.260 --> 01:45:56.580
defined
01:45:56.580 --> 01:45:56.940
over here
01:45:56.940 --> 01:45:57.100
so
01:45:57.100 --> 01:45:57.300
we'll
01:45:57.300 --> 01:45:57.480
just
01:45:57.480 --> 01:45:57.840
reusing
01:45:57.840 --> 01:45:58.280
that
01:45:58.280 --> 01:45:58.780
so
01:45:58.780 --> 01:45:59.520
this is like
01:45:59.520 --> 01:46:00.300
a layer by layer
01:46:00.300 --> 01:46:00.860
implementation
01:46:00.860 --> 01:46:01.880
first you will be
01:46:01.880 --> 01:46:02.180
defining
01:46:02.180 --> 01:46:02.880
this layer
01:46:02.880 --> 01:46:03.660
and just
01:46:04.740 --> 01:46:05.540
pushing that
01:46:05.540 --> 01:46:06.060
into different
01:46:06.060 --> 01:46:06.420
file
01:46:06.420 --> 01:46:06.740
so that
01:46:06.740 --> 01:46:07.020
you can
01:46:07.020 --> 01:46:07.260
reuse
01:46:07.260 --> 01:46:07.880
everywhere
01:46:07.880 --> 01:46:08.300
inside
01:46:08.300 --> 01:46:08.960
another project
01:46:08.960 --> 01:46:09.480
as well
01:46:09.480 --> 01:46:10.400
and once
01:46:10.400 --> 01:46:10.880
you
01:46:10.880 --> 01:46:11.140
define
01:46:11.140 --> 01:46:11.420
that
01:46:11.420 --> 01:46:12.120
somewhere else
01:46:12.120 --> 01:46:12.480
you're
01:46:12.480 --> 01:46:12.720
just
01:46:12.720 --> 01:46:13.000
importing
01:46:13.000 --> 01:46:13.400
that
01:46:13.400 --> 01:46:13.980
into your
01:46:13.980 --> 01:46:14.200
current
01:46:14.200 --> 01:46:14.580
project
01:46:14.580 --> 01:46:14.980
I mean
01:46:14.980 --> 01:46:15.460
into your
01:46:15.460 --> 01:46:15.680
current
01:46:15.680 --> 01:46:16.220
implementation
01:46:16.220 --> 01:46:16.600
API
01:46:16.600 --> 01:46:17.460
and you'll
01:46:17.460 --> 01:46:17.620
be
01:46:17.620 --> 01:46:17.880
implementing
01:46:17.880 --> 01:46:18.220
that
01:46:18.220 --> 01:46:18.500
how
01:46:18.500 --> 01:46:18.780
you want
01:46:18.780 --> 01:46:19.100
to implement
01:46:19.100 --> 01:46:19.260
that
01:46:20.560 --> 01:46:21.120
is
01:46:21.120 --> 01:46:21.620
just
01:46:21.620 --> 01:46:21.880
bringing
01:46:21.880 --> 01:46:22.180
that
01:46:22.180 --> 01:46:22.700
and
01:46:22.700 --> 01:46:22.980
using
01:46:22.980 --> 01:46:23.260
dot
01:46:23.260 --> 01:46:23.560
syntax
01:46:23.560 --> 01:46:23.960
that I've
01:46:23.960 --> 01:46:24.220
already
01:46:24.220 --> 01:46:24.500
told
01:46:24.500 --> 01:46:25.240
so by
01:46:25.240 --> 01:46:25.760
using this
01:46:25.760 --> 01:46:26.360
dot syntax
01:46:26.360 --> 01:46:26.840
we'll
01:46:26.840 --> 01:46:27.180
just
01:46:27.180 --> 01:46:27.620
refer
01:46:28.200 --> 01:46:28.760
already
01:46:28.780 --> 01:46:29.360
imported
01:46:29.360 --> 01:46:30.060
implementation
01:46:30.060 --> 01:46:30.620
so
01:46:31.240 --> 01:46:31.780
inside
01:46:31.780 --> 01:46:31.980
this
01:46:32.760 --> 01:46:33.620
I mean
01:46:33.620 --> 01:46:34.140
you are
01:46:34.140 --> 01:46:34.700
just
01:46:36.000 --> 01:46:36.660
fetching
01:46:36.660 --> 01:46:36.900
the
01:46:36.900 --> 01:46:37.280
details
01:46:37.280 --> 01:46:37.620
called
01:46:37.620 --> 01:46:38.060
category
01:46:38.060 --> 01:46:38.840
but what
01:46:38.840 --> 01:46:39.140
exactly
01:46:39.140 --> 01:46:39.480
is this
01:46:39.480 --> 01:46:39.820
category
01:46:39.820 --> 01:46:40.180
you don't
01:46:40.180 --> 01:46:40.560
have any
01:46:40.560 --> 01:46:40.740
idea
01:46:40.740 --> 01:46:41.080
right now
01:46:41.080 --> 01:46:41.540
right
01:46:41.540 --> 01:46:42.320
so if you
01:46:42.320 --> 01:46:42.460
wanted
01:46:42.460 --> 01:46:42.800
to
01:46:42.800 --> 01:46:43.160
understand
01:46:43.160 --> 01:46:43.420
what
01:46:43.420 --> 01:46:43.700
exactly
01:46:43.700 --> 01:46:43.860
is
01:46:43.860 --> 01:46:44.040
this
01:46:44.040 --> 01:46:44.360
category
01:46:44.360 --> 01:46:45.020
you have
01:46:45.020 --> 01:46:45.280
to go
01:46:45.280 --> 01:46:45.640
to this
01:46:45.640 --> 01:46:45.940
specific
01:46:45.940 --> 01:46:46.600
implementation
01:46:46.600 --> 01:46:47.260
inside
01:46:47.260 --> 01:46:47.520
the
01:46:47.520 --> 01:46:47.720
exchange
01:46:47.720 --> 01:46:48.060
modules
01:46:48.060 --> 01:46:49.080
and then
01:46:49.080 --> 01:46:49.260
just
01:46:49.780 --> 01:46:50.400
you know
01:46:50.400 --> 01:46:50.660
go
01:46:50.660 --> 01:46:51.340
that
01:46:51.340 --> 01:46:52.520
understand
01:46:53.540 --> 01:46:54.200
how
01:46:55.000 --> 01:46:55.660
this
01:46:55.660 --> 01:46:56.420
category
01:46:56.420 --> 01:46:56.700
is
01:46:56.700 --> 01:46:57.060
defined
01:46:57.060 --> 01:46:57.800
like
01:46:57.800 --> 01:46:58.220
what
01:46:58.220 --> 01:46:58.580
exactly
01:46:58.580 --> 01:46:59.200
rules
01:46:59.200 --> 01:46:59.500
for
01:46:59.500 --> 01:46:59.700
this
01:46:59.700 --> 01:47:00.080
category
01:47:00.960 --> 01:47:01.440
I
01:47:01.440 --> 01:47:02.340
think
01:47:02.940 --> 01:47:03.420
it
01:47:03.420 --> 01:47:03.740
consists
01:47:03.740 --> 01:47:03.860
of
01:47:04.500 --> 01:47:04.940
something
01:47:04.940 --> 01:47:05.220
like
01:47:05.220 --> 01:47:05.420
this
01:47:05.420 --> 01:47:05.680
that
01:47:05.680 --> 01:47:05.920
I
01:47:05.920 --> 01:47:06.160
that
01:47:06.160 --> 01:47:06.480
we've
01:47:06.480 --> 01:47:06.700
already
01:47:06.700 --> 01:47:07.280
discussed
01:47:07.280 --> 01:47:07.520
like
01:47:07.520 --> 01:47:07.820
I'll
01:47:07.820 --> 01:47:07.920
show
01:47:07.920 --> 01:47:08.160
you
01:47:08.160 --> 01:47:08.320
this
01:47:08.320 --> 01:47:08.480
rule
01:47:08.480 --> 01:47:08.720
all
01:47:08.720 --> 01:47:08.980
this
01:47:12.040 --> 01:47:12.520
yeah
01:47:12.520 --> 01:47:13.040
something
01:47:13.040 --> 01:47:13.280
like
01:47:13.280 --> 01:47:13.680
this
01:47:13.680 --> 01:47:14.140
so we
01:47:14.140 --> 01:47:14.260
for
01:47:14.260 --> 01:47:14.720
we have
01:47:14.720 --> 01:47:15.020
product
01:47:15.020 --> 01:47:15.620
and
01:47:15.620 --> 01:47:15.960
each and
01:47:15.960 --> 01:47:16.200
where
01:47:16.200 --> 01:47:16.660
each and
01:47:16.660 --> 01:47:16.860
every
01:47:16.860 --> 01:47:17.040
product
01:47:17.040 --> 01:47:17.460
has its
01:47:17.460 --> 01:47:17.620
own
01:47:17.620 --> 01:47:18.040
properties
01:47:18.040 --> 01:47:18.440
like
01:47:18.440 --> 01:47:18.860
identifier
01:47:18.860 --> 01:47:19.300
category
01:47:19.300 --> 01:47:19.600
area
01:47:19.600 --> 01:47:20.100
brand
01:47:20.100 --> 01:47:20.500
and all
01:47:20.500 --> 01:47:21.100
so for
01:47:21.100 --> 01:47:21.320
product
01:47:21.320 --> 01:47:21.700
also
01:47:21.700 --> 01:47:21.900
I mean
01:47:21.900 --> 01:47:22.160
for
01:47:22.160 --> 01:47:22.440
category
01:47:22.440 --> 01:47:22.880
also
01:47:22.880 --> 01:47:23.360
it has
01:47:23.360 --> 01:47:23.580
something
01:47:29.080 --> 01:47:30.100
in which
01:47:30.100 --> 01:47:30.640
year
01:47:30.640 --> 01:47:31.300
this category
01:47:31.300 --> 01:47:32.040
is introduced
01:47:32.040 --> 01:47:32.820
or
01:47:32.820 --> 01:47:33.280
what is
01:47:33.280 --> 01:47:33.620
the turnover
01:47:33.620 --> 01:47:34.040
of this
01:47:34.040 --> 01:47:34.280
category
01:47:34.280 --> 01:47:34.660
so
01:47:34.660 --> 01:47:35.160
those are
01:47:35.160 --> 01:47:35.580
the attributes
01:47:35.580 --> 01:47:36.380
that are
01:47:36.380 --> 01:47:36.580
present
01:47:36.580 --> 01:47:37.220
for that
01:47:37.220 --> 01:47:37.980
specific
01:47:37.980 --> 01:47:38.540
implementation
01:47:38.540 --> 01:47:39.380
okay
01:47:39.380 --> 01:47:39.820
so
01:47:39.820 --> 01:47:40.240
like
01:47:40.240 --> 01:47:40.920
right now
01:47:40.920 --> 01:47:41.440
we'll just
01:47:41.440 --> 01:47:41.660
import
01:47:41.660 --> 01:47:41.920
that
01:47:41.920 --> 01:47:42.340
and use
01:47:42.340 --> 01:47:42.560
this
01:47:42.560 --> 01:47:42.820
so that
01:47:43.360 --> 01:47:44.020
we can
01:47:44.020 --> 01:47:44.200
have
01:47:44.200 --> 01:47:44.340
the
01:47:44.340 --> 01:47:44.620
usability
01:47:44.620 --> 01:47:44.880
over
01:47:44.880 --> 01:47:45.400
there
01:47:45.400 --> 01:47:46.340
that is
01:47:46.340 --> 01:47:46.980
one thing
01:47:47.560 --> 01:47:48.120
and
01:47:48.120 --> 01:47:48.820
it comes
01:47:48.820 --> 01:47:49.140
to the
01:47:49.140 --> 01:47:49.600
response
01:47:50.380 --> 01:47:50.940
how
01:47:50.940 --> 01:47:51.740
a
01:47:51.740 --> 01:47:51.940
single
01:47:53.480 --> 01:47:54.400
API endpoint
01:47:54.400 --> 01:47:54.720
is
01:47:54.720 --> 01:47:55.100
defined
01:47:56.080 --> 01:47:56.640
okay
01:47:56.640 --> 01:47:57.340
so
01:47:57.340 --> 01:47:57.860
right now
01:47:57.860 --> 01:48:00.420
is one of the
01:48:00.420 --> 01:48:01.080
REST API that
01:48:01.080 --> 01:48:01.460
we have
01:48:01.460 --> 01:48:01.860
defined
01:48:01.860 --> 01:48:02.160
I mean
01:48:02.160 --> 01:48:02.520
discussed
01:48:02.520 --> 01:48:02.580
for
01:48:03.600 --> 01:48:04.000
ML
01:48:04.000 --> 01:48:04.760
implementation
01:48:06.060 --> 01:48:06.960
let me
01:48:06.960 --> 01:48:07.660
just
01:48:07.660 --> 01:48:08.040
take a
01:48:08.040 --> 01:48:08.260
break
01:48:08.260 --> 01:48:08.960
of
01:48:08.960 --> 01:48:09.320
let me
01:48:09.320 --> 01:48:09.640
just
01:48:09.640 --> 01:48:10.320
get some
01:48:10.320 --> 01:48:10.420
water
01:48:11.240 --> 01:48:11.840
we'll
01:48:11.840 --> 01:48:12.000
connect
01:48:12.000 --> 01:48:12.480
after 10
01:48:12.480 --> 01:48:12.640
minutes
01:48:13.360 --> 01:48:13.960
maybe
01:48:13.960 --> 01:48:14.640
yeah
01:48:14.640 --> 01:48:15.680
sure
01:48:33.900 --> 01:48:34.540
yeah
01:48:35.920 --> 01:48:37.200
you back
01:48:38.640 --> 01:48:39.280
yeah
01:48:39.280 --> 01:48:39.780
let's just
01:48:42.280 --> 01:48:42.920
so
01:48:44.300 --> 01:48:45.200
that would
01:48:45.200 --> 01:48:45.760
be
01:48:45.760 --> 01:48:46.520
one of
01:48:46.520 --> 01:48:46.740
the
01:48:46.740 --> 01:48:47.220
get requests
01:48:47.220 --> 01:48:47.700
that we
01:48:47.700 --> 01:48:47.860
have
01:48:47.860 --> 01:48:48.620
designed
01:48:48.620 --> 01:48:49.320
till now
01:48:49.320 --> 01:48:49.840
so
01:48:49.840 --> 01:48:50.480
let's say
01:48:50.480 --> 01:48:51.060
we have
01:48:51.780 --> 01:48:52.320
few more
01:48:52.320 --> 01:48:52.900
requests
01:48:52.900 --> 01:48:53.900
that are
01:48:53.900 --> 01:48:54.080
tightly
01:48:54.080 --> 01:48:54.400
coupled
01:48:54.400 --> 01:48:54.860
with this
01:48:54.860 --> 01:48:55.360
get request
01:48:55.360 --> 01:48:56.040
let's say
01:48:56.040 --> 01:48:56.240
for
01:48:56.240 --> 01:48:56.420
example
01:48:57.860 --> 01:48:58.400
for
01:48:58.980 --> 01:48:59.620
YouTube is
01:49:00.620 --> 01:49:01.140
best example
01:49:01.140 --> 01:49:01.380
let's say
01:49:04.620 --> 01:49:05.340
let's say
01:49:05.340 --> 01:49:05.900
you want to
01:49:05.900 --> 01:49:06.320
go for
01:49:06.320 --> 01:49:06.740
subscriptions
01:49:07.460 --> 01:49:08.520
if you see
01:49:08.520 --> 01:49:09.860
inside the
01:49:09.860 --> 01:49:10.100
feed
01:49:10.100 --> 01:49:10.720
you have
01:49:10.720 --> 01:49:11.020
different
01:49:11.860 --> 01:49:12.340
you have
01:49:12.340 --> 01:49:12.880
a different
01:49:12.880 --> 01:49:13.360
endpoint
01:49:13.360 --> 01:49:13.680
called
01:49:13.680 --> 01:49:14.340
subscriptions
01:49:14.340 --> 01:49:15.140
endpoint
01:49:15.140 --> 01:49:15.880
let's say
01:49:15.880 --> 01:49:16.180
you don't
01:49:16.180 --> 01:49:16.480
want to
01:49:16.480 --> 01:49:16.800
go for
01:49:16.800 --> 01:49:17.280
subscriptions
01:49:17.780 --> 01:49:18.300
let's say
01:49:18.300 --> 01:49:18.580
you have
01:49:19.700 --> 01:49:20.300
adjust
01:49:21.140 --> 01:49:21.540
with the
01:49:22.660 --> 01:49:23.260
feed
01:49:23.260 --> 01:49:24.120
it will
01:49:24.120 --> 01:49:24.640
provide
01:49:24.640 --> 01:49:25.080
a list
01:49:25.080 --> 01:49:25.340
of
01:49:25.340 --> 01:49:25.820
recommendations
01:49:25.820 --> 01:49:26.340
for you
01:49:26.340 --> 01:49:26.920
and you
01:49:26.920 --> 01:49:27.080
don't
01:49:27.080 --> 01:49:27.480
want to
01:49:27.480 --> 01:49:27.680
have
01:49:27.680 --> 01:49:28.460
random recommendations
01:49:28.460 --> 01:49:29.160
from random
01:49:29.160 --> 01:49:29.560
YouTube
01:49:29.560 --> 01:49:30.200
so you
01:49:30.200 --> 01:49:30.520
want to
01:49:30.520 --> 01:49:31.280
get only
01:49:31.280 --> 01:49:31.820
recommendations
01:49:31.820 --> 01:49:32.160
from
01:49:32.160 --> 01:49:32.700
your
01:49:32.700 --> 01:49:32.920
own
01:49:32.920 --> 01:49:33.360
subscriptions
01:49:33.360 --> 01:49:34.080
so you
01:49:34.080 --> 01:49:34.320
just
01:49:34.320 --> 01:49:34.560
hit this
01:49:35.180 --> 01:49:36.200
subscriptions
01:49:36.200 --> 01:49:36.920
endpoint
01:49:36.920 --> 01:49:37.440
so
01:49:39.600 --> 01:49:40.140
I want you
01:49:40.140 --> 01:49:40.240
to
01:49:40.240 --> 01:49:40.860
understand
01:49:40.860 --> 01:49:41.500
how
01:49:41.500 --> 01:49:41.840
we are
01:49:41.840 --> 01:49:42.340
passing
01:49:42.340 --> 01:49:43.160
different
01:49:43.160 --> 01:49:43.820
parameters
01:49:43.820 --> 01:49:44.340
or
01:49:44.340 --> 01:49:44.640
different
01:49:47.000 --> 01:49:47.880
route
01:49:47.880 --> 01:49:48.300
path
01:49:48.300 --> 01:49:48.920
that we
01:49:48.920 --> 01:49:49.140
are
01:49:49.140 --> 01:49:49.520
providing
01:49:49.520 --> 01:49:49.940
for
01:49:49.940 --> 01:49:50.620
a route path
01:49:50.620 --> 01:49:51.380
basically
01:49:51.380 --> 01:49:52.700
that's how
01:49:52.700 --> 01:49:53.500
we'll be
01:49:53.500 --> 01:49:53.780
designing
01:49:53.780 --> 01:49:54.480
a new
01:49:55.380 --> 01:49:55.820
path
01:49:55.820 --> 01:49:56.480
inside this
01:49:57.680 --> 01:49:58.620
categories endpoint
01:49:59.440 --> 01:50:00.340
that's way
01:50:00.340 --> 01:50:01.200
we'll be
01:50:01.200 --> 01:50:01.660
giving a
01:50:01.660 --> 01:50:01.840
slash
01:50:02.960 --> 01:50:03.680
inside
01:50:03.680 --> 01:50:04.840
categories endpoint
01:50:04.840 --> 01:50:05.360
if you see
01:50:05.360 --> 01:50:06.160
over here
01:50:07.360 --> 01:50:08.540
there is a
01:50:08.540 --> 01:50:08.900
new line
01:50:08.900 --> 01:50:09.520
between
01:50:09.520 --> 01:50:09.800
in the
01:50:09.800 --> 01:50:10.860
61st line
01:50:10.860 --> 01:50:11.680
and
01:50:11.680 --> 01:50:12.440
44th line
01:50:12.440 --> 01:50:13.140
if you compare
01:50:13.140 --> 01:50:13.660
the new lines
01:50:13.660 --> 01:50:13.920
here
01:50:14.580 --> 01:50:15.280
if you see
01:50:16.280 --> 01:50:16.720
it is
01:50:17.440 --> 01:50:18.080
the
01:50:18.080 --> 01:50:18.820
61st line
01:50:18.820 --> 01:50:19.240
is the
01:50:19.240 --> 01:50:19.800
child of
01:50:19.800 --> 01:50:20.960
44th line
01:50:20.960 --> 01:50:21.880
so it is
01:50:21.880 --> 01:50:22.360
one of
01:50:22.360 --> 01:50:22.660
the
01:50:22.660 --> 01:50:23.320
object
01:50:23.320 --> 01:50:24.120
of
01:50:24.120 --> 01:50:24.880
44th line
01:50:25.600 --> 01:50:26.120
we
01:50:27.680 --> 01:50:28.360
object
01:50:28.360 --> 01:50:29.220
specifications
01:50:30.640 --> 01:50:30.640
so
01:50:32.300 --> 01:50:33.280
if you want
01:50:33.280 --> 01:50:33.440
to
01:50:33.440 --> 01:50:33.840
understand
01:50:33.840 --> 01:50:34.300
in the
01:50:34.300 --> 01:50:34.360
it
01:50:34.360 --> 01:50:34.620
in a
01:50:34.620 --> 01:50:34.860
layman
01:50:34.860 --> 01:50:35.120
language
01:50:37.940 --> 01:50:39.300
let's say
01:50:39.300 --> 01:50:40.320
categories
01:50:40.320 --> 01:50:41.180
provides us
01:50:41.180 --> 01:50:41.480
a list
01:50:41.480 --> 01:50:41.660
of
01:50:41.660 --> 01:50:42.080
categories
01:50:42.080 --> 01:50:43.020
but
01:50:43.020 --> 01:50:43.700
if you
01:50:43.700 --> 01:50:44.020
want to
01:50:44.020 --> 01:50:44.180
fetch
01:50:44.180 --> 01:50:44.800
a specific
01:50:44.800 --> 01:50:45.220
category
01:50:45.220 --> 01:50:46.120
then you'll
01:50:46.120 --> 01:50:46.260
be
01:50:46.260 --> 01:50:46.580
passing
01:50:46.580 --> 01:50:47.140
category
01:50:47.140 --> 01:50:47.580
id
01:50:49.120 --> 01:50:50.000
so this
01:50:50.000 --> 01:50:50.280
is the
01:50:50.280 --> 01:50:50.480
random
01:50:50.480 --> 01:50:50.760
id that
01:50:50.760 --> 01:50:51.240
we provide
01:50:51.240 --> 01:50:52.360
so this
01:50:52.360 --> 01:50:52.700
random
01:50:52.700 --> 01:50:53.360
id is
01:50:53.360 --> 01:50:53.720
captured
01:50:53.720 --> 01:50:54.180
by the
01:50:54.180 --> 01:50:54.320
variable
01:50:54.840 --> 01:50:55.500
called
01:50:55.500 --> 01:50:56.640
category
01:50:56.640 --> 01:50:56.980
id
01:51:03.280 --> 01:51:04.440
that is
01:51:04.440 --> 01:51:05.280
I mean that
01:51:05.280 --> 01:51:05.760
since this
01:51:05.760 --> 01:51:06.080
is
01:51:06.080 --> 01:51:06.460
variable
01:51:06.460 --> 01:51:07.420
it will
01:51:07.420 --> 01:51:07.780
change
01:51:07.780 --> 01:51:08.760
every time
01:51:08.760 --> 01:51:09.660
it's not a
01:51:09.660 --> 01:51:10.340
static one
01:51:10.340 --> 01:51:11.380
so
01:51:11.380 --> 01:51:12.000
that's
01:51:12.000 --> 01:51:12.600
the reason
01:51:13.120 --> 01:51:13.520
we have
01:51:14.380 --> 01:51:14.860
provided
01:51:14.860 --> 01:51:15.780
static
01:51:15.780 --> 01:51:16.200
paths
01:51:16.200 --> 01:51:16.580
or
01:51:16.580 --> 01:51:16.840
static
01:51:16.840 --> 01:51:17.240
routes
01:51:17.240 --> 01:51:18.400
as
01:51:18.400 --> 01:51:18.760
a normal
01:51:18.760 --> 01:51:19.180
text
01:51:19.180 --> 01:51:19.600
but
01:51:20.120 --> 01:51:21.100
variable
01:51:21.100 --> 01:51:21.400
ones
01:51:21.400 --> 01:51:21.680
we should
01:51:22.400 --> 01:51:22.740
always
01:51:22.740 --> 01:51:23.460
change
01:51:23.460 --> 01:51:24.220
them
01:51:24.220 --> 01:51:25.020
as a
01:51:25.020 --> 01:51:25.340
category
01:51:25.340 --> 01:51:25.700
id
01:51:26.400 --> 01:51:26.780
so
01:51:26.780 --> 01:51:27.400
if you see
01:51:27.400 --> 01:51:28.000
over here
01:51:28.000 --> 01:51:28.740
it will
01:51:28.740 --> 01:51:29.720
have this
01:51:29.720 --> 01:51:30.460
category as
01:51:30.460 --> 01:51:31.000
I mean the
01:51:31.000 --> 01:51:31.160
category
01:51:31.160 --> 01:51:31.680
id as
01:51:31.680 --> 01:51:32.120
parameters
01:51:32.880 --> 01:51:33.520
so
01:51:33.520 --> 01:51:34.200
what exactly
01:51:34.200 --> 01:51:34.500
the
01:51:34.500 --> 01:51:34.880
parameters
01:51:35.660 --> 01:51:36.040
this
01:51:36.040 --> 01:51:36.560
ui
01:51:36.560 --> 01:51:36.860
this
01:51:36.860 --> 01:51:37.120
uri
01:51:37.120 --> 01:51:37.560
parameters
01:51:37.560 --> 01:51:38.040
is a
01:51:38.040 --> 01:51:39.320
built-in
01:51:39.320 --> 01:51:39.780
ram and
01:51:40.500 --> 01:51:41.140
languages
01:51:42.660 --> 01:51:43.300
methodology
01:51:43.300 --> 01:51:43.800
actually
01:51:43.800 --> 01:51:44.580
it will
01:51:44.580 --> 01:51:45.360
describe
01:51:46.080 --> 01:51:47.040
what exactly
01:51:47.040 --> 01:51:47.280
the
01:51:47.280 --> 01:51:47.520
parameters
01:51:47.520 --> 01:51:47.880
that we
01:51:47.880 --> 01:51:48.100
will be
01:51:48.100 --> 01:51:48.320
passing
01:51:48.320 --> 01:51:49.260
so here
01:51:49.260 --> 01:51:49.760
the
01:51:49.760 --> 01:51:50.020
parameter
01:51:50.020 --> 01:51:50.300
is
01:51:50.300 --> 01:51:50.660
category
01:51:50.660 --> 01:51:50.940
id
01:51:50.940 --> 01:51:51.900
this is
01:51:51.900 --> 01:51:52.080
like
01:51:52.080 --> 01:51:52.580
much more
01:51:52.580 --> 01:51:53.020
similar to
01:51:54.000 --> 01:51:54.640
something
01:51:56.820 --> 01:51:58.500
the question mark
01:51:58.500 --> 01:51:59.180
and the natural
01:51:59.180 --> 01:51:59.800
category id
01:52:01.560 --> 01:52:02.780
so that's how
01:52:02.780 --> 01:52:03.120
this
01:52:03.120 --> 01:52:03.380
url
01:52:03.380 --> 01:52:03.680
works
01:52:04.540 --> 01:52:04.800
and
01:52:04.800 --> 01:52:05.400
here
01:52:05.400 --> 01:52:05.760
we have
01:52:05.760 --> 01:52:06.100
provided
01:52:06.100 --> 01:52:06.660
the
01:52:06.660 --> 01:52:07.320
configuration
01:52:07.320 --> 01:52:07.900
for
01:52:07.900 --> 01:52:08.300
what this
01:52:09.020 --> 01:52:09.700
specific
01:52:09.700 --> 01:52:10.180
end point
01:52:10.180 --> 01:52:10.960
should do
01:52:10.960 --> 01:52:11.600
it will
01:52:11.600 --> 01:52:11.740
also
01:52:11.740 --> 01:52:12.220
just
01:52:12.220 --> 01:52:12.740
get
01:52:12.740 --> 01:52:13.060
the
01:52:13.060 --> 01:52:13.580
category
01:52:13.580 --> 01:52:14.120
of a
01:52:14.120 --> 01:52:14.360
specific
01:52:14.360 --> 01:52:14.680
category
01:52:14.680 --> 01:52:14.820
id
01:52:14.820 --> 01:52:15.160
which is
01:52:15.160 --> 01:52:15.520
already
01:52:15.520 --> 01:52:16.060
passed
01:52:16.060 --> 01:52:16.940
as a
01:52:17.560 --> 01:52:17.760
uri
01:52:17.760 --> 01:52:18.280
parameter
01:52:19.180 --> 01:52:19.620
so
01:52:19.620 --> 01:52:20.200
and also
01:52:20.200 --> 01:52:20.400
here
01:52:20.400 --> 01:52:20.720
we have
01:52:20.720 --> 01:52:21.140
responses
01:52:21.140 --> 01:52:21.680
since this
01:52:21.680 --> 01:52:21.860
is
01:52:21.860 --> 01:52:22.520
get request
01:52:22.520 --> 01:52:23.540
will mostly
01:52:23.540 --> 01:52:24.120
design
01:52:24.120 --> 01:52:24.220
this
01:52:25.380 --> 01:52:26.060
specific
01:52:26.060 --> 01:52:26.760
get request
01:52:26.760 --> 01:52:27.220
to provide
01:52:27.220 --> 01:52:27.820
the 200
01:52:27.820 --> 01:52:28.380
responses
01:52:28.380 --> 01:52:28.940
similar to
01:52:28.940 --> 01:52:29.220
do
01:52:29.220 --> 01:52:29.820
similar to
01:52:29.820 --> 01:52:29.960
that
01:52:30.740 --> 01:52:31.240
itself
01:52:32.660 --> 01:52:33.260
and
01:52:33.800 --> 01:52:34.360
if you
01:52:34.360 --> 01:52:34.500
see
01:52:34.500 --> 01:52:34.680
you
01:52:34.680 --> 01:52:34.820
over
01:52:34.820 --> 01:52:35.400
here
01:52:36.040 --> 01:52:36.640
this
01:52:36.640 --> 01:52:37.220
there is
01:52:37.220 --> 01:52:37.320
another
01:52:39.120 --> 01:52:39.720
route
01:52:39.720 --> 01:52:40.160
path
01:52:40.160 --> 01:52:41.000
this route
01:52:41.000 --> 01:52:41.180
path
01:52:41.180 --> 01:52:41.480
is
01:52:41.480 --> 01:52:41.880
mostly
01:52:41.880 --> 01:52:42.440
the
01:52:42.440 --> 01:52:42.520
product
01:52:43.200 --> 01:52:43.800
path
01:52:43.800 --> 01:52:44.840
basically
01:52:45.480 --> 01:52:46.260
you have
01:52:46.260 --> 01:52:46.640
to understand
01:52:46.640 --> 01:52:47.240
like this
01:52:47.240 --> 01:52:47.820
it's
01:52:47.820 --> 01:52:47.960
like
01:52:47.960 --> 01:52:48.440
kind of
01:52:48.440 --> 01:52:48.560
tree
01:52:48.560 --> 01:52:48.920
basically
01:52:50.100 --> 01:52:50.900
we have
01:52:50.900 --> 01:52:51.320
categories
01:52:51.320 --> 01:52:51.720
as a
01:52:51.720 --> 01:52:51.920
parent
01:52:51.920 --> 01:52:52.520
path
01:52:53.180 --> 01:52:53.780
inside
01:52:53.780 --> 01:52:54.080
this
01:52:54.080 --> 01:52:54.380
categories
01:52:54.380 --> 01:52:54.820
path
01:52:54.820 --> 01:52:55.240
we have
01:52:55.240 --> 01:52:55.500
lot
01:52:55.500 --> 01:52:55.800
of
01:52:55.800 --> 01:52:56.200
categories
01:52:56.900 --> 01:52:57.460
and
01:52:57.460 --> 01:52:57.820
for each
01:52:57.820 --> 01:52:58.160
and every
01:52:58.160 --> 01:52:58.560
category
01:52:58.560 --> 01:52:59.160
you have
01:52:59.160 --> 01:52:59.700
lots of
01:52:59.700 --> 01:53:00.220
products
01:53:01.380 --> 01:53:01.940
see
01:53:02.440 --> 01:53:03.120
for each
01:53:03.120 --> 01:53:03.420
and every
01:53:03.420 --> 01:53:03.800
category
01:53:03.800 --> 01:53:03.960
id
01:53:03.960 --> 01:53:04.340
you have
01:53:04.340 --> 01:53:04.680
different
01:53:04.680 --> 01:53:05.180
products
01:53:05.180 --> 01:53:05.880
so it's
01:53:05.880 --> 01:53:06.380
a kind of
01:53:06.380 --> 01:53:07.140
catalogs
01:53:07.140 --> 01:53:07.680
you can say
01:53:07.680 --> 01:53:08.400
so
01:53:08.400 --> 01:53:09.060
this can be
01:53:09.060 --> 01:53:09.400
translated
01:53:09.400 --> 01:53:09.740
like
01:53:09.740 --> 01:53:10.340
this
01:53:11.540 --> 01:53:12.320
you have
01:53:12.320 --> 01:53:12.780
categories
01:53:12.780 --> 01:53:14.080
and then
01:53:14.080 --> 01:53:14.520
you'll be
01:53:14.520 --> 01:53:14.840
passing
01:53:14.840 --> 01:53:15.460
a category
01:53:15.460 --> 01:53:15.780
id
01:53:15.780 --> 01:53:16.740
for this
01:53:16.740 --> 01:53:17.180
you wanted
01:53:17.180 --> 01:53:17.440
to
01:53:17.440 --> 01:53:17.740
fetch
01:53:17.740 --> 01:53:18.260
what are
01:53:18.260 --> 01:53:18.580
the products
01:53:18.580 --> 01:53:18.920
for this
01:53:18.920 --> 01:53:19.200
category
01:53:19.200 --> 01:53:19.520
id
01:53:19.520 --> 01:53:20.340
then you'll
01:53:20.340 --> 01:53:20.740
be
01:53:20.740 --> 01:53:20.940
hitting
01:53:20.940 --> 01:53:21.280
this
01:53:27.940 --> 01:53:28.660
so
01:53:29.420 --> 01:53:29.480
this
01:53:30.140 --> 01:53:30.920
let's say
01:53:30.920 --> 01:53:31.060
when
01:53:31.060 --> 01:53:31.320
user
01:53:31.320 --> 01:53:31.540
hits
01:53:31.540 --> 01:53:31.640
this
01:53:33.640 --> 01:53:34.360
request
01:53:34.360 --> 01:53:34.740
inside
01:53:34.740 --> 01:53:34.840
his
01:53:35.740 --> 01:53:36.160
API
01:53:36.160 --> 01:53:36.560
client
01:53:36.560 --> 01:53:37.020
whether
01:53:37.020 --> 01:53:37.260
that
01:53:37.260 --> 01:53:37.560
may be
01:53:37.560 --> 01:53:38.000
postman
01:53:38.000 --> 01:53:38.180
or
01:53:38.180 --> 01:53:38.380
call
01:53:38.380 --> 01:53:38.720
request
01:53:38.720 --> 01:53:39.420
or
01:53:39.420 --> 01:53:39.640
a
01:53:39.640 --> 01:53:40.360
typical
01:53:40.360 --> 01:53:40.880
wget
01:53:40.880 --> 01:53:41.360
response
01:53:41.360 --> 01:53:41.600
or
01:53:41.600 --> 01:53:41.980
typical
01:53:41.980 --> 01:53:42.440
wget
01:53:42.440 --> 01:53:42.980
response
01:53:42.980 --> 01:53:43.600
or
01:53:43.600 --> 01:53:43.940
wget
01:53:43.940 --> 01:53:44.200
request
01:53:45.180 --> 01:53:45.900
that
01:53:45.900 --> 01:53:46.180
request
01:53:46.180 --> 01:53:46.540
will be
01:53:46.540 --> 01:53:46.800
routed
01:53:46.800 --> 01:53:47.040
over
01:53:47.040 --> 01:53:47.440
here
01:53:47.440 --> 01:53:47.920
these
01:53:47.920 --> 01:53:48.440
products
01:53:48.440 --> 01:53:49.140
here
01:53:49.140 --> 01:53:49.560
so
01:53:50.460 --> 01:53:51.100
and again
01:53:51.100 --> 01:53:51.600
this is
01:53:51.600 --> 01:53:51.780
get
01:53:51.780 --> 01:53:52.160
API
01:53:53.440 --> 01:53:54.160
so
01:53:54.160 --> 01:53:54.380
we'll
01:53:54.380 --> 01:53:54.540
be
01:53:54.540 --> 01:53:54.900
providing
01:53:54.900 --> 01:53:55.260
a
01:53:55.260 --> 01:53:55.780
display name
01:53:55.780 --> 01:53:56.080
and
01:53:56.080 --> 01:53:56.300
what
01:53:56.300 --> 01:53:56.900
the description
01:53:56.900 --> 01:53:57.260
that this
01:53:58.300 --> 01:53:58.520
API
01:53:58.520 --> 01:53:58.960
does
01:53:58.960 --> 01:53:59.760
and what are
01:53:59.760 --> 01:54:00.020
the query
01:54:00.020 --> 01:54:00.500
parameters
01:54:00.500 --> 01:54:01.420
and what
01:54:01.420 --> 01:54:01.820
the
01:54:01.820 --> 01:54:02.040
response
01:54:02.040 --> 01:54:02.260
it
01:54:02.260 --> 01:54:02.440
provides
01:54:03.680 --> 01:54:04.280
so
01:54:04.280 --> 01:54:05.140
that is
01:54:05.140 --> 01:54:05.420
till now
01:54:06.700 --> 01:54:07.380
when it
01:54:07.380 --> 01:54:07.620
comes
01:54:07.620 --> 01:54:08.200
to categories
01:54:08.200 --> 01:54:08.600
API
01:54:09.520 --> 01:54:10.280
this is
01:54:10.280 --> 01:54:10.560
one of
01:54:10.560 --> 01:54:10.740
the
01:54:10.740 --> 01:54:11.040
parent
01:54:12.360 --> 01:54:12.960
and
01:54:12.960 --> 01:54:13.920
you have
01:54:13.920 --> 01:54:14.160
this
01:54:14.160 --> 01:54:14.420
another
01:54:14.420 --> 01:54:14.660
parent
01:54:14.660 --> 01:54:14.920
called
01:54:14.920 --> 01:54:15.220
products
01:54:15.220 --> 01:54:15.640
parent
01:54:16.380 --> 01:54:16.840
so
01:54:16.840 --> 01:54:17.220
basically
01:54:17.220 --> 01:54:17.560
this
01:54:17.560 --> 01:54:17.720
products
01:54:17.720 --> 01:54:18.100
parent
01:54:18.100 --> 01:54:18.740
again
01:54:18.740 --> 01:54:19.120
this
01:54:19.120 --> 01:54:19.500
is the
01:54:19.500 --> 01:54:20.000
same
01:54:20.000 --> 01:54:20.520
like
01:54:20.520 --> 01:54:20.840
till now
01:54:20.840 --> 01:54:21.160
we are
01:54:21.160 --> 01:54:21.320
seeing
01:54:21.320 --> 01:54:21.780
only
01:54:22.800 --> 01:54:23.400
the
01:54:23.400 --> 01:54:23.900
get
01:54:23.900 --> 01:54:24.420
request
01:54:24.420 --> 01:54:25.300
right now
01:54:25.300 --> 01:54:25.760
we haven't
01:54:25.760 --> 01:54:26.400
seen any
01:54:26.400 --> 01:54:27.220
post request
01:54:27.760 --> 01:54:28.340
we'll be
01:54:28.340 --> 01:54:28.880
creating a
01:54:28.880 --> 01:54:29.800
post request
01:54:30.320 --> 01:54:31.020
right now
01:54:31.020 --> 01:54:31.280
so that
01:54:32.380 --> 01:54:33.580
by ourselves
01:54:33.580 --> 01:54:34.160
so that
01:54:34.760 --> 01:54:35.880
you know
01:54:35.880 --> 01:54:36.600
we'll
01:54:36.600 --> 01:54:37.040
have
01:54:37.040 --> 01:54:37.500
idea
01:54:37.500 --> 01:54:38.120
like
01:54:38.120 --> 01:54:38.560
what should
01:54:38.560 --> 01:54:39.040
be
01:54:39.040 --> 01:54:39.480
the things
01:54:39.480 --> 01:54:39.940
that we're
01:54:39.940 --> 01:54:40.220
gonna
01:54:40.220 --> 01:54:40.780
you know
01:54:40.780 --> 01:54:41.340
take care
01:54:41.340 --> 01:54:41.840
while
01:54:41.840 --> 01:54:42.440
creating
01:54:43.460 --> 01:54:44.140
specific
01:54:44.140 --> 01:54:44.480
API
01:54:44.480 --> 01:54:45.020
implementations
01:54:45.020 --> 01:54:45.780
by ourselves
01:54:45.780 --> 01:54:46.600
okay
01:54:46.600 --> 01:54:47.220
let me
01:54:47.220 --> 01:54:47.820
just create
01:54:47.820 --> 01:54:48.080
a
01:54:48.080 --> 01:54:48.320
playground
01:54:48.320 --> 01:54:48.660
over
01:54:49.380 --> 01:54:50.060
here
01:54:51.700 --> 01:54:52.380
yeah
01:54:52.380 --> 01:54:53.400
you can say
01:54:53.400 --> 01:54:53.860
right
01:54:53.860 --> 01:54:54.480
the screen
01:54:55.380 --> 01:54:55.860
basically
01:54:55.860 --> 01:54:56.540
it's in design center
01:54:56.540 --> 01:54:56.820
right now
01:54:57.920 --> 01:54:58.640
yeah
01:54:59.720 --> 01:55:00.440
so
01:55:00.440 --> 01:55:00.840
right now
01:55:00.840 --> 01:55:01.160
we'll be
01:55:01.160 --> 01:55:01.620
creating
01:55:01.620 --> 01:55:02.560
everything
01:55:02.560 --> 01:55:03.060
from scratch
01:55:05.280 --> 01:55:06.160
at least
01:55:06.160 --> 01:55:06.380
for
01:55:06.380 --> 01:55:06.680
post
01:55:06.680 --> 01:55:07.180
API
01:55:07.180 --> 01:55:07.820
by taking
01:55:07.820 --> 01:55:08.120
consider
01:55:08.120 --> 01:55:08.480
into
01:55:08.480 --> 01:55:09.500
like
01:55:09.500 --> 01:55:10.000
whatever
01:55:10.000 --> 01:55:10.260
we
01:55:10.920 --> 01:55:11.520
discuss
01:55:11.520 --> 01:55:12.000
till now
01:55:12.000 --> 01:55:12.320
so
01:55:12.320 --> 01:55:12.820
first
01:55:13.460 --> 01:55:13.900
this
01:55:13.900 --> 01:55:14.340
comes under
01:55:14.340 --> 01:55:14.800
like
01:55:14.800 --> 01:55:15.000
API
01:55:15.000 --> 01:55:15.480
designing
01:55:15.480 --> 01:55:16.220
part
01:55:16.220 --> 01:55:16.580
of
01:55:17.640 --> 01:55:17.800
new
01:55:17.800 --> 01:55:18.000
soft
01:55:18.000 --> 01:55:18.580
basically
01:55:18.580 --> 01:55:19.460
so
01:55:19.460 --> 01:55:19.920
let's say
01:55:19.920 --> 01:55:20.260
you wanted
01:55:20.260 --> 01:55:20.940
to create
01:55:20.940 --> 01:55:21.620
a
01:55:21.620 --> 01:55:22.360
post request
01:55:22.360 --> 01:55:22.900
or
01:55:22.900 --> 01:55:23.420
post
01:55:23.420 --> 01:55:23.940
catalog
01:55:23.940 --> 01:55:24.720
or
01:55:24.720 --> 01:55:25.320
post product
01:55:25.320 --> 01:55:25.960
let's say
01:55:25.960 --> 01:55:26.480
the main
01:55:26.480 --> 01:55:26.780
agenda
01:55:26.780 --> 01:55:27.620
for this
01:55:27.620 --> 01:55:29.200
API is to
01:55:29.840 --> 01:55:30.440
post
01:55:30.440 --> 01:55:31.320
a product
01:55:32.480 --> 01:55:33.400
to the
01:55:33.400 --> 01:55:33.760
database
01:55:36.620 --> 01:55:38.020
this is
01:55:38.020 --> 01:55:38.620
one of
01:55:38.620 --> 01:55:38.800
the
01:55:38.800 --> 01:55:39.180
agenda
01:55:39.980 --> 01:55:40.680
and
01:55:40.680 --> 01:55:40.960
first
01:55:40.960 --> 01:55:41.400
we have to
01:55:41.400 --> 01:55:42.020
understand
01:55:42.020 --> 01:55:42.780
what is
01:55:43.960 --> 01:55:44.660
the
01:55:44.660 --> 01:55:45.060
the route
01:55:45.060 --> 01:55:45.740
typically
01:55:45.740 --> 01:55:46.780
the best
01:55:46.780 --> 01:55:47.180
convention
01:55:47.180 --> 01:55:47.680
is to
01:55:47.680 --> 01:55:48.220
follow
01:55:48.220 --> 01:55:48.880
the same
01:55:49.720 --> 01:55:50.240
routes
01:55:50.240 --> 01:55:50.740
that are
01:55:50.740 --> 01:55:50.980
already
01:55:50.980 --> 01:55:51.380
there
01:55:51.380 --> 01:55:52.220
till now
01:55:52.220 --> 01:55:53.080
so for us
01:55:53.080 --> 01:55:53.920
it is
01:55:53.920 --> 01:55:54.100
already
01:55:54.100 --> 01:55:54.620
there
01:55:54.720 --> 01:55:56.240
but the product out is already there
01:55:56.240 --> 01:55:57.720
so we just use that itself
01:55:58.640 --> 01:55:59.160
then
01:55:59.160 --> 01:56:00.360
user will be confused
01:56:01.760 --> 01:56:02.800
what is the get request
01:56:02.800 --> 01:56:04.100
and what is the post request
01:56:04.100 --> 01:56:05.760
so we have to handle that
01:56:07.900 --> 01:56:08.420
while
01:56:08.420 --> 01:56:09.660
pushing the API itself
01:56:09.660 --> 01:56:09.920
I mean
01:56:09.920 --> 01:56:10.200
while
01:56:10.200 --> 01:56:11.160
hitting the API
01:56:11.160 --> 01:56:11.960
a user
01:56:13.120 --> 01:56:14.160
has this
01:56:14.160 --> 01:56:14.720
control over
01:56:16.520 --> 01:56:17.360
API method
01:56:17.360 --> 01:56:18.680
he is
01:56:18.680 --> 01:56:19.060
posting
01:56:19.060 --> 01:56:19.940
or
01:56:19.940 --> 01:56:20.720
hitting towards
01:56:20.720 --> 01:56:21.440
so
01:56:21.440 --> 01:56:21.700
I mean
01:56:21.700 --> 01:56:22.680
we have this
01:56:22.680 --> 01:56:23.240
hands-on session
01:56:23.240 --> 01:56:23.580
with the
01:56:23.580 --> 01:56:23.840
postman
01:56:24.400 --> 01:56:24.800
tool
01:56:24.800 --> 01:56:25.620
so with that
01:56:25.620 --> 01:56:26.560
we can understand
01:56:26.560 --> 01:56:28.300
how the user can understand
01:56:28.300 --> 01:56:30.160
what is the
01:56:30.160 --> 01:56:31.060
request that is his
01:56:31.060 --> 01:56:31.700
that he is hitting
01:56:32.440 --> 01:56:33.420
so for this
01:56:33.420 --> 01:56:35.060
we will be providing the description
01:56:35.680 --> 01:56:36.800
for this description
01:56:36.800 --> 01:56:37.680
we just provide
01:56:39.600 --> 01:56:40.160
like
01:56:41.600 --> 01:56:42.720
to post
01:56:42.720 --> 01:56:43.440
a new
01:56:44.820 --> 01:56:45.380
product
01:56:47.440 --> 01:56:48.440
to catalog
01:56:49.180 --> 01:56:49.740
and
01:56:49.740 --> 01:56:50.980
what is the API method
01:56:50.980 --> 01:56:51.900
that we have discussed
01:56:51.900 --> 01:56:53.100
it is post method
01:56:54.140 --> 01:56:56.220
so whenever let's say
01:56:56.220 --> 01:56:56.880
user
01:56:56.880 --> 01:56:57.680
came here
01:56:59.040 --> 01:56:59.680
and
01:56:59.680 --> 01:57:00.700
user wanted to see
01:57:00.700 --> 01:57:01.660
what this
01:57:01.660 --> 01:57:02.280
API does
01:57:02.280 --> 01:57:03.080
in a
01:57:03.080 --> 01:57:03.980
you know
01:57:03.980 --> 01:57:05.100
very concise manner
01:57:05.760 --> 01:57:06.780
here we will be providing
01:57:06.780 --> 01:57:07.680
a display name
01:57:07.680 --> 01:57:09.260
this display name
01:57:09.260 --> 01:57:09.980
is a attribute
01:57:09.980 --> 01:57:11.100
which is a built-in attribute
01:57:11.100 --> 01:57:11.720
again
01:57:11.720 --> 01:57:12.700
in newsoft
01:57:12.700 --> 01:57:13.820
this display name
01:57:13.820 --> 01:57:14.880
provides us
01:57:14.880 --> 01:57:15.620
an option
01:57:15.620 --> 01:57:17.000
to provide a concise name
01:57:17.000 --> 01:57:17.940
so that
01:57:17.940 --> 01:57:18.620
user can
01:57:18.620 --> 01:57:19.760
see what exactly this
01:57:20.440 --> 01:57:22.100
this specific API does
01:57:22.100 --> 01:57:22.540
basically
01:57:23.960 --> 01:57:24.480
post
01:57:24.480 --> 01:57:25.540
a new product
01:57:25.540 --> 01:57:26.640
that's all
01:57:26.640 --> 01:57:27.780
and then
01:57:27.780 --> 01:57:28.420
we just provide
01:57:28.420 --> 01:57:29.720
the description of this request
01:57:29.720 --> 01:57:30.960
the first and foremost thing is
01:57:32.800 --> 01:57:33.320
unnamed
01:57:33.320 --> 01:57:33.900
syntax
01:57:34.400 --> 01:57:35.120
so white lines
01:57:35.120 --> 01:57:36.460
that we are having right now
01:57:36.460 --> 01:57:38.140
if you have any mistake over here
01:57:38.140 --> 01:57:39.180
then the program
01:57:39.720 --> 01:57:41.120
API will not be compiling
01:57:41.120 --> 01:57:41.940
and it will be throwing
01:57:41.940 --> 01:57:42.640
a lot of errors
01:57:44.320 --> 01:57:46.060
we will have to double shoot
01:57:46.060 --> 01:57:47.300
what exactly the error
01:57:47.300 --> 01:57:48.280
has happened
01:57:48.280 --> 01:57:49.120
mostly
01:57:49.120 --> 01:57:50.420
for beginners
01:57:50.420 --> 01:57:51.740
the errors will be coming
01:57:52.520 --> 01:57:53.560
from this
01:57:54.520 --> 01:57:55.980
like the white spaces
01:57:55.980 --> 01:57:57.000
for this yaml
01:57:57.000 --> 01:57:58.240
until you get familiarized
01:57:58.240 --> 01:57:59.500
with the yaml-based syntax
01:57:59.500 --> 01:58:00.540
and get used to
01:58:00.540 --> 01:58:01.340
yaml-based syntax
01:58:01.340 --> 01:58:02.140
each and
01:58:02.140 --> 01:58:03.220
if you have provided
01:58:03.220 --> 01:58:04.360
a single
01:58:04.360 --> 01:58:04.900
white line
01:58:04.900 --> 01:58:06.000
white space over here
01:58:06.000 --> 01:58:07.080
then you can mistake
01:58:09.000 --> 01:58:09.600
description
01:58:09.600 --> 01:58:10.320
we will be providing
01:58:10.320 --> 01:58:11.220
the same description
01:58:11.220 --> 01:58:12.420
so but
01:58:12.420 --> 01:58:13.880
you have these two descriptions
01:58:13.880 --> 01:58:14.200
right
01:58:14.200 --> 01:58:15.280
what exactly the difference
01:58:15.280 --> 01:58:16.060
between them
01:58:16.060 --> 01:58:17.080
this description is
01:58:18.040 --> 01:58:18.640
more
01:58:18.640 --> 01:58:19.720
concentrated towards this
01:58:20.860 --> 01:58:21.660
root level API
01:58:21.660 --> 01:58:22.680
but this description
01:58:22.680 --> 01:58:23.320
is mostly
01:58:23.320 --> 01:58:24.700
concentrated towards the
01:58:24.700 --> 01:58:26.020
post method
01:58:26.020 --> 01:58:26.920
let's say for
01:58:27.660 --> 01:58:28.640
only product API
01:58:28.640 --> 01:58:29.920
you have two methods
01:58:29.920 --> 01:58:30.600
like get method
01:58:30.600 --> 01:58:31.420
and post method
01:58:31.420 --> 01:58:32.380
then you
01:58:32.380 --> 01:58:33.580
you should have two descriptions
01:58:33.580 --> 01:58:34.400
right
01:58:34.400 --> 01:58:34.900
the get
01:58:34.900 --> 01:58:35.620
for get request
01:58:35.620 --> 01:58:36.680
there should be one request
01:58:36.680 --> 01:58:37.420
one description
01:58:37.420 --> 01:58:38.120
and for post
01:58:38.120 --> 01:58:38.580
there should be
01:58:38.580 --> 01:58:39.360
another description
01:58:39.360 --> 01:58:40.360
so this is
01:58:41.520 --> 01:58:43.220
HTTP method level description
01:58:43.220 --> 01:58:44.640
and this is
01:58:44.640 --> 01:58:45.760
API level description
01:58:47.480 --> 01:58:49.880
so but the best
01:58:49.880 --> 01:58:51.640
description for this is
01:58:51.640 --> 01:58:52.600
prod manage
01:58:52.600 --> 01:58:54.000
product management
01:58:55.320 --> 01:58:56.440
to avoid confusions
01:59:08.120 --> 01:59:09.600
and query parameters
01:59:10.200 --> 01:59:11.260
so based on
01:59:11.260 --> 01:59:12.840
your specific application
01:59:12.840 --> 01:59:13.920
and based on
01:59:13.920 --> 01:59:14.840
your specific business
01:59:14.840 --> 01:59:15.460
requirements
01:59:15.460 --> 01:59:16.520
and based on
01:59:18.920 --> 01:59:20.820
the consumers applications
01:59:21.320 --> 01:59:22.020
requirements
01:59:22.020 --> 01:59:24.080
I mean will be defining
01:59:24.080 --> 01:59:25.180
our query parameters
01:59:25.180 --> 01:59:25.880
over here
01:59:25.880 --> 01:59:27.120
there are a lot of
01:59:27.120 --> 01:59:28.100
query parameters
01:59:28.100 --> 01:59:29.220
and all of them
01:59:29.220 --> 01:59:29.860
are dynamic
01:59:29.860 --> 01:59:30.940
so MuleSoft is
01:59:30.940 --> 01:59:31.860
not going to complain
01:59:31.860 --> 01:59:33.100
that you have provided
01:59:33.100 --> 01:59:33.940
this specific query
01:59:33.940 --> 01:59:34.480
parameter
01:59:34.480 --> 01:59:35.900
or something like that
01:59:35.900 --> 01:59:36.740
but only thing
01:59:37.560 --> 01:59:38.260
which is
01:59:40.160 --> 01:59:41.560
which should be defined
01:59:41.560 --> 01:59:42.300
is
01:59:42.300 --> 01:59:43.480
this query parameters
01:59:43.480 --> 01:59:45.120
definition over here
01:59:45.120 --> 01:59:47.500
this should be
01:59:48.320 --> 01:59:49.020
standalone
01:59:49.020 --> 01:59:51.060
and MuleSoft defined syntax
01:59:51.060 --> 01:59:52.480
so this should not be changed
01:59:52.480 --> 01:59:52.740
even
01:59:53.340 --> 01:59:54.860
capital P to small p
01:59:54.860 --> 01:59:56.080
you can't modify that
01:59:56.080 --> 01:59:57.220
but after this
01:59:57.940 --> 01:59:58.740
query parameters
01:59:58.740 --> 01:59:59.780
you can write
01:59:59.780 --> 02:00:00.820
anything of your
02:00:01.480 --> 02:00:03.640
basically all of these are
02:00:03.640 --> 02:00:04.580
dynamic streams
02:00:05.140 --> 02:00:05.620
let's say
02:00:06.140 --> 02:00:07.280
for this specific
02:00:07.280 --> 02:00:08.360
product designing
02:00:09.220 --> 02:00:10.340
we want to maintain
02:00:11.360 --> 02:00:12.560
price of the product
02:00:12.560 --> 02:00:12.820
maybe
02:00:13.960 --> 02:00:14.640
yeah
02:00:14.640 --> 02:00:15.340
we have that
02:00:15.340 --> 02:00:16.040
and that should be
02:00:16.040 --> 02:00:17.060
a compulsory query
02:00:17.060 --> 02:00:17.880
query parameter
02:00:17.880 --> 02:00:19.020
so we'll not be passing
02:00:19.020 --> 02:00:19.960
any koshimak symbol
02:00:19.960 --> 02:00:20.540
over there
02:00:21.060 --> 02:00:22.420
and we'll just describe
02:00:24.220 --> 02:00:25.440
mostly this
02:00:25.440 --> 02:00:26.180
price should be
02:00:26.180 --> 02:00:27.060
a floating point integer
02:00:29.200 --> 02:00:29.840
float
02:00:30.520 --> 02:00:31.160
so
02:00:31.160 --> 02:00:32.340
and again yeah
02:00:32.340 --> 02:00:33.080
just for nothing
02:00:33.080 --> 02:00:34.220
I forgot to implement
02:00:34.220 --> 02:00:35.060
I forgot to type
02:00:35.060 --> 02:00:36.560
so we have
02:00:36.560 --> 02:00:37.500
data types inside
02:00:37.500 --> 02:00:38.920
this MuleSoft
02:00:38.920 --> 02:00:39.580
basically
02:00:39.580 --> 02:00:40.740
a data type
02:00:40.740 --> 02:00:41.780
in a MuleSoft
02:00:41.780 --> 02:00:42.440
there are like
02:00:42.440 --> 02:00:43.220
lot of data types
02:00:43.220 --> 02:00:43.540
we have
02:00:44.640 --> 02:00:45.280
strings
02:00:45.280 --> 02:00:46.180
which are
02:00:48.160 --> 02:00:49.060
alphabetical strings
02:00:49.060 --> 02:00:49.760
basically
02:00:51.060 --> 02:00:52.280
we can call them as
02:00:52.280 --> 02:00:52.800
sentences
02:00:52.800 --> 02:00:53.860
or words
02:00:55.100 --> 02:00:55.740
with
02:00:55.740 --> 02:00:56.480
white space
02:00:56.480 --> 02:00:57.280
between them
02:00:57.280 --> 02:00:58.760
and we have
02:00:58.760 --> 02:00:59.580
integers
02:01:00.300 --> 02:01:01.560
integers consist of
02:01:01.560 --> 02:01:02.520
only whole number
02:01:02.520 --> 02:01:02.880
integers
02:01:02.880 --> 02:01:03.560
basically
02:01:03.560 --> 02:01:04.500
it can't
02:01:05.960 --> 02:01:06.460
contain
02:01:06.460 --> 02:01:07.940
decimal values
02:01:07.940 --> 02:01:08.760
basically for
02:01:08.760 --> 02:01:09.340
decimal values
02:01:09.340 --> 02:01:10.480
or pointed
02:01:11.380 --> 02:01:12.020
numbers
02:01:12.020 --> 02:01:12.760
we'll be having
02:01:12.760 --> 02:01:13.900
float as a data type
02:01:13.900 --> 02:01:14.980
and we also have
02:01:16.140 --> 02:01:16.780
Boolean
02:01:16.780 --> 02:01:17.620
let's say for
02:01:17.620 --> 02:01:18.500
few of these scenarios
02:01:18.500 --> 02:01:20.240
there might be
02:01:20.240 --> 02:01:21.040
true or false
02:01:22.720 --> 02:01:23.320
implementations
02:01:23.320 --> 02:01:24.720
in those scenarios
02:01:25.300 --> 02:01:26.120
Boolean will be
02:01:26.120 --> 02:01:26.420
the better
02:01:27.360 --> 02:01:27.920
data point
02:01:27.920 --> 02:01:28.800
that we're going to choose
02:01:28.800 --> 02:01:29.780
so mostly
02:01:29.780 --> 02:01:31.020
these will be the
02:01:31.020 --> 02:01:32.260
and we also have this
02:01:34.960 --> 02:01:36.060
object data type
02:01:36.060 --> 02:01:36.960
so for custom
02:01:36.960 --> 02:01:37.480
implementation
02:01:37.480 --> 02:01:38.360
so we have this
02:01:38.360 --> 02:01:38.900
custom
02:01:38.900 --> 02:01:40.340
object data type
02:01:40.340 --> 02:01:41.300
so mostly this is
02:01:42.740 --> 02:01:43.900
not a preliminary
02:01:43.900 --> 02:01:44.680
data type
02:01:44.680 --> 02:01:45.840
this is
02:01:45.840 --> 02:01:47.040
more complex data type
02:01:47.040 --> 02:01:48.060
which consists of
02:01:48.060 --> 02:01:48.780
all the
02:01:48.780 --> 02:01:49.080
strings
02:01:49.080 --> 02:01:49.520
integers
02:01:49.520 --> 02:01:50.020
floats
02:01:50.020 --> 02:01:51.040
these
02:01:51.040 --> 02:01:52.160
all will be
02:01:52.160 --> 02:01:52.780
embedded inside
02:01:52.780 --> 02:01:53.620
this object data type
02:01:53.620 --> 02:01:54.420
basically
02:01:54.420 --> 02:01:55.820
that's how it works
02:01:55.820 --> 02:01:56.880
yeah back to
02:01:56.880 --> 02:01:57.260
implementation
02:01:57.260 --> 02:01:58.280
yeah we have this
02:01:58.280 --> 02:01:58.820
price
02:01:58.820 --> 02:01:59.840
and it
02:01:59.840 --> 02:02:00.640
corresponds to
02:02:00.640 --> 02:02:01.040
float
02:02:01.040 --> 02:02:01.900
and again
02:02:01.900 --> 02:02:03.400
let's just think of
02:02:03.400 --> 02:02:04.400
another thing
02:02:05.380 --> 02:02:06.060
maybe
02:02:06.800 --> 02:02:07.680
name of the product
02:02:11.700 --> 02:02:12.680
typically names
02:02:12.680 --> 02:02:14.040
will be
02:02:14.040 --> 02:02:14.660
sentences
02:02:15.280 --> 02:02:16.080
so we can use
02:02:16.080 --> 02:02:16.680
string
02:02:17.440 --> 02:02:17.520
and
02:02:18.460 --> 02:02:19.940
based on business
02:02:19.940 --> 02:02:21.440
we want to have
02:02:21.440 --> 02:02:21.980
expiry date
02:02:21.980 --> 02:02:23.480
of this product as well
02:02:23.480 --> 02:02:24.500
that is one of the
02:02:24.500 --> 02:02:25.120
hard rule of
02:02:25.120 --> 02:02:25.680
implementation
02:02:26.560 --> 02:02:27.160
that
02:02:28.060 --> 02:02:29.460
people want to give
02:02:29.460 --> 02:02:30.500
so expiry date
02:02:32.060 --> 02:02:33.900
so it depends upon us
02:02:33.900 --> 02:02:34.840
how we want to design
02:02:34.840 --> 02:02:35.560
this
02:02:35.560 --> 02:02:36.320
specific
02:02:36.320 --> 02:02:37.300
API implementation
02:02:38.200 --> 02:02:39.240
and expiry date
02:02:39.240 --> 02:02:39.620
mostly
02:02:41.820 --> 02:02:43.020
would be
02:02:43.020 --> 02:02:43.560
strings
02:02:43.560 --> 02:02:44.520
but we also have
02:02:44.520 --> 02:02:45.820
enum data type
02:02:45.820 --> 02:02:46.640
that is specific
02:02:46.640 --> 02:02:47.920
to Java implementation
02:02:47.920 --> 02:02:49.420
and we have this
02:02:49.420 --> 02:02:50.960
based methodology
02:02:50.960 --> 02:02:51.860
over here
02:02:51.860 --> 02:02:52.420
inside
02:02:52.420 --> 02:02:53.240
MuleSoft
02:02:53.240 --> 02:02:54.000
we'll be discussing
02:02:54.000 --> 02:02:55.300
that with the help of
02:02:55.300 --> 02:02:56.000
Anypoint Studio
02:02:56.000 --> 02:02:57.280
when it comes to there
02:02:57.280 --> 02:02:58.600
I'll be
02:02:58.600 --> 02:02:59.460
describing how to
02:02:59.460 --> 02:02:59.820
integrate
02:02:59.820 --> 02:03:00.980
Java based
02:03:00.980 --> 02:03:01.520
scripts or
02:03:01.520 --> 02:03:02.300
Python based scripts
02:03:02.300 --> 02:03:02.940
inside MuleSoft
02:03:03.600 --> 02:03:04.280
but yeah
02:03:04.280 --> 02:03:04.960
we can just
02:03:06.060 --> 02:03:06.940
string over here
02:03:08.240 --> 02:03:09.080
and yeah
02:03:09.080 --> 02:03:09.720
so these are the
02:03:09.720 --> 02:03:10.520
query parameters
02:03:12.000 --> 02:03:13.200
now let's
02:03:13.200 --> 02:03:13.740
go with the
02:03:13.740 --> 02:03:14.800
response model
02:03:18.000 --> 02:03:19.540
so for responses
02:03:20.340 --> 02:03:21.240
we have to
02:03:21.240 --> 02:03:21.860
handle a couple of
02:03:21.860 --> 02:03:22.480
scenarios over here
02:03:23.300 --> 02:03:24.140
because since
02:03:24.140 --> 02:03:25.180
this is post request
02:03:25.180 --> 02:03:26.560
this is much more
02:03:26.560 --> 02:03:27.140
complicated
02:03:27.140 --> 02:03:28.800
when it compared to
02:03:28.800 --> 02:03:30.040
when we compared to
02:03:30.040 --> 02:03:30.780
get request
02:03:30.780 --> 02:03:31.520
because
02:03:31.520 --> 02:03:32.280
I mean
02:03:32.280 --> 02:03:32.760
get requests
02:03:32.760 --> 02:03:33.660
are mostly
02:03:33.660 --> 02:03:34.640
200 request or
02:03:36.020 --> 02:03:36.820
404 request
02:03:36.820 --> 02:03:37.380
that's all
02:03:37.380 --> 02:03:39.160
but for post request
02:03:39.160 --> 02:03:40.520
we have to handle
02:03:40.520 --> 02:03:41.180
couple of other
02:03:41.180 --> 02:03:42.260
scenarios as well
02:03:42.260 --> 02:03:43.060
let's say
02:03:43.060 --> 02:03:43.600
first we'll go
02:03:43.600 --> 02:03:44.120
with positive
02:03:44.120 --> 02:03:44.600
scenarios
02:03:45.380 --> 02:03:46.120
201
02:03:47.200 --> 02:03:48.080
so for this
02:03:48.080 --> 02:03:49.000
specific response
02:03:49.000 --> 02:03:49.780
let's say
02:03:49.780 --> 02:03:50.420
we're providing
02:03:53.560 --> 02:03:54.880
a lot of typos
02:03:55.820 --> 02:03:57.660
which is passing
02:04:11.260 --> 02:04:13.200
so for response
02:04:13.200 --> 02:04:14.220
we have two things
02:04:14.220 --> 02:04:15.100
which is embedded
02:04:15.100 --> 02:04:16.000
one is
02:04:16.000 --> 02:04:17.040
response status code
02:04:17.040 --> 02:04:18.080
which is this one
02:04:18.080 --> 02:04:19.360
and response body
02:04:19.360 --> 02:04:20.360
so basically
02:04:20.360 --> 02:04:21.120
a response body
02:04:21.120 --> 02:04:21.660
consists of
02:04:22.920 --> 02:04:23.940
a JSON format
02:04:23.940 --> 02:04:25.120
as I've already told
02:04:25.120 --> 02:04:26.020
so basically
02:04:26.020 --> 02:04:26.900
this JSON format
02:04:26.900 --> 02:04:27.540
will be
02:04:27.540 --> 02:04:28.620
I mean
02:04:28.620 --> 02:04:29.880
will be describing
02:04:29.880 --> 02:04:31.180
MuleSoft
02:04:31.180 --> 02:04:31.420
to
02:04:32.260 --> 02:04:33.560
use JSON as
02:04:33.560 --> 02:04:34.620
hard rule
02:04:35.180 --> 02:04:35.760
so
02:04:35.760 --> 02:04:36.400
similarly
02:04:36.400 --> 02:04:37.360
we'll be providing
02:04:37.360 --> 02:04:38.160
application slash
02:04:38.160 --> 02:04:39.260
JSON over here
02:04:39.260 --> 02:04:40.180
so that
02:04:40.180 --> 02:04:41.340
MuleSoft can understand
02:04:41.900 --> 02:04:42.640
what exactly
02:04:42.640 --> 02:04:44.080
the response format
02:04:44.080 --> 02:04:44.320
should be
02:04:45.720 --> 02:04:46.880
and then type
02:04:50.420 --> 02:04:51.480
will be just
02:04:51.480 --> 02:04:52.000
using this
02:04:53.400 --> 02:04:54.840
JSON response over here
02:04:55.520 --> 02:04:56.520
as an example
02:04:56.520 --> 02:04:57.300
since this is
02:04:57.300 --> 02:04:59.280
product implementation only
02:04:59.280 --> 02:05:00.700
so that should be fine
02:05:01.520 --> 02:05:02.380
but this
02:05:02.380 --> 02:05:02.820
I mean
02:05:02.820 --> 02:05:03.340
this should be
02:05:03.340 --> 02:05:05.000
already coming from
02:05:05.000 --> 02:05:05.820
already other
02:05:05.820 --> 02:05:06.980
developer module
02:05:07.640 --> 02:05:08.620
basically I've told
02:05:08.620 --> 02:05:09.040
will be
02:05:09.620 --> 02:05:10.840
breaking up modules
02:05:10.840 --> 02:05:11.680
and just importing
02:05:11.680 --> 02:05:12.100
the modules
02:05:12.100 --> 02:05:13.000
again and again
02:05:13.000 --> 02:05:13.800
so that we
02:05:13.800 --> 02:05:14.360
can achieve
02:05:16.980 --> 02:05:17.620
modularity
02:05:17.620 --> 02:05:18.600
inside the MuleSoft
02:05:18.600 --> 02:05:19.360
implementations
02:05:19.360 --> 02:05:20.240
so that's why
02:05:20.240 --> 02:05:21.020
we're just referencing
02:05:21.020 --> 02:05:21.980
this over here
02:05:21.980 --> 02:05:22.500
or else
02:05:22.500 --> 02:05:22.920
we have to
02:05:23.600 --> 02:05:24.800
start defining
02:05:24.800 --> 02:05:25.440
type
02:05:25.440 --> 02:05:26.480
from here
02:05:26.480 --> 02:05:27.500
and it will be like
02:05:28.600 --> 02:05:29.240
multiple
02:05:29.240 --> 02:05:29.940
multiple nestings
02:05:29.940 --> 02:05:30.640
and
02:05:30.640 --> 02:05:31.620
project gonna be messy
02:05:31.620 --> 02:05:32.660
if we don't
02:05:32.660 --> 02:05:33.240
reuse things
02:05:34.180 --> 02:05:34.820
over
02:05:34.820 --> 02:05:36.140
different implementations
02:05:36.140 --> 02:05:37.380
so that's how it works
02:05:37.380 --> 02:05:37.940
basically
02:05:38.620 --> 02:05:40.220
so you have this
02:05:40.220 --> 02:05:41.280
you've got my point
02:05:41.280 --> 02:05:43.160
so this is one of the
02:05:44.060 --> 02:05:46.840
best I mean
02:05:46.840 --> 02:05:47.720
positive scenario
02:05:47.720 --> 02:05:48.580
let's say
02:05:48.580 --> 02:05:49.900
user is not at all authorized
02:05:49.900 --> 02:05:51.120
to do this operation
02:05:51.120 --> 02:05:51.800
like
02:05:51.800 --> 02:05:52.540
creating a product
02:05:52.540 --> 02:05:54.200
so in that scenario
02:05:54.200 --> 02:05:54.920
we have to provide
02:05:55.780 --> 02:05:57.080
bad response
02:05:58.100 --> 02:05:59.360
so 401
02:05:59.360 --> 02:06:01.020
provides us unauthorized
02:06:01.640 --> 02:06:02.500
so how
02:06:02.500 --> 02:06:03.420
we're going to be handling
02:06:03.420 --> 02:06:04.140
this
02:06:04.140 --> 02:06:05.480
of 401 response
02:06:05.480 --> 02:06:06.600
so basically
02:06:09.940 --> 02:06:11.220
we'll be providing
02:06:11.220 --> 02:06:12.620
first description to this
02:06:13.180 --> 02:06:14.320
let me just
02:06:14.320 --> 02:06:15.100
capture the description
02:06:15.100 --> 02:06:15.500
and then
02:06:16.340 --> 02:06:16.860
you wanna write
02:06:27.660 --> 02:06:28.740
and then
02:06:28.740 --> 02:06:30.180
we don't pass any
02:06:30.180 --> 02:06:31.480
body for 401
02:06:31.480 --> 02:06:31.820
because
02:06:32.920 --> 02:06:34.180
it itself is like
02:06:34.180 --> 02:06:35.080
something is fishy
02:06:35.080 --> 02:06:36.400
because user did not
02:06:36.400 --> 02:06:37.040
pass any headers
02:06:37.040 --> 02:06:38.360
to this specific implementation
02:06:38.360 --> 02:06:39.500
so we don't want to
02:06:39.500 --> 02:06:40.240
reveal any details
02:06:40.240 --> 02:06:41.420
so that's why
02:06:41.420 --> 02:06:42.420
it's best practice
02:06:43.140 --> 02:06:44.560
and not to provide any body
02:06:44.560 --> 02:06:46.500
but no one stops you
02:06:46.500 --> 02:06:47.420
from providing body
02:06:47.420 --> 02:06:48.640
so we have to adhere
02:06:48.640 --> 02:06:49.620
to the best practices
02:06:49.620 --> 02:06:51.560
and stop providing
02:06:51.560 --> 02:06:53.760
bodies for 401 responses
02:06:53.760 --> 02:06:55.360
we should only provide
02:06:55.360 --> 02:06:56.620
user is not authorized
02:06:56.620 --> 02:06:57.480
to create the product
02:06:57.480 --> 02:06:58.500
and we don't need to pass
02:06:58.500 --> 02:06:59.900
even the username as well
02:06:59.900 --> 02:07:00.580
because that is
02:07:01.720 --> 02:07:03.140
deviating from the best practices
02:07:03.140 --> 02:07:04.160
let's say
02:07:04.160 --> 02:07:05.460
user is authenticated
02:07:05.460 --> 02:07:07.460
to the
02:07:07.460 --> 02:07:08.180
implementation
02:07:08.180 --> 02:07:08.980
but he's not
02:07:10.660 --> 02:07:11.260
having
02:07:11.260 --> 02:07:13.020
enough privileges to do this
02:07:13.020 --> 02:07:13.760
so in that scenario
02:07:13.760 --> 02:07:15.660
we'll be passing 403
02:07:15.660 --> 02:07:16.140
over here
02:07:18.840 --> 02:07:19.400
and
02:07:19.400 --> 02:07:21.200
we'll be passing the description
02:07:22.380 --> 02:07:22.940
again
02:07:25.040 --> 02:07:26.860
so that's how this one works
02:07:26.860 --> 02:07:27.460
so mostly
02:07:27.460 --> 02:07:28.320
this will be the
02:07:28.320 --> 02:07:29.440
implementation scenario
02:07:30.140 --> 02:07:31.500
maybe let's go for
02:07:31.500 --> 02:07:32.220
one of the exercises
02:07:32.220 --> 02:07:33.260
right now
02:07:33.260 --> 02:07:34.040
if you're comfortable
02:07:34.040 --> 02:07:35.180
shall we do this
02:07:36.400 --> 02:07:38.360
let me just paste this
02:07:38.360 --> 02:07:39.580
in chat box right now
02:07:40.160 --> 02:07:41.240
and you can share
02:07:41.240 --> 02:07:41.840
your screen
02:07:41.840 --> 02:07:43.160
and start creating
02:07:43.160 --> 02:07:44.140
one of the implementation
02:07:44.140 --> 02:07:45.400
I'll just paste this
02:07:45.400 --> 02:07:45.960
in the chat box
02:07:49.920 --> 02:07:50.920
so that you can have
02:07:50.920 --> 02:07:52.360
some reference
02:08:07.480 --> 02:08:08.940
yeah I can see it
02:08:14.520 --> 02:08:17.340
okay you have any notepad with you
02:08:17.340 --> 02:08:17.920
notepad
02:08:26.920 --> 02:08:29.160
let me just paste one
02:08:30.540 --> 02:08:32.120
so I'll just give you
02:08:32.120 --> 02:08:33.940
a scenario basically right now
02:08:33.940 --> 02:08:36.540
we wanted to create an API
02:08:37.560 --> 02:08:40.240
for one of the application
02:08:40.240 --> 02:08:42.520
which provides
02:08:42.520 --> 02:08:43.040
a list of
02:08:45.960 --> 02:08:46.480
services
02:08:46.480 --> 02:08:47.500
that is going to be providing
02:08:47.500 --> 02:08:48.760
so the end point
02:08:48.760 --> 02:08:49.900
will be slash services
02:08:50.760 --> 02:08:52.400
and we wanted to handle
02:08:53.840 --> 02:08:55.360
posting a new service
02:08:55.360 --> 02:08:57.100
and deleting a new service
02:08:57.100 --> 02:08:57.540
sorry
02:08:57.540 --> 02:08:59.620
deleting an existing service
02:09:08.320 --> 02:09:11.660
which is yeah thank you
