MCPA MuleSoft Certified Platform Architect Level 1 – Designing Effective APIs Part 4

6. HTTP Caching – Detailed

Hi, let us discuss about caching in this particular lecture in more detail. So, like we discussed in the previous lectures, the Http caching actually helps to serve the responses for particular APIs, right? From the Http layer or Caching layer without having to go all the way down to the downstream system and the back end systems, right? So we discussed at high level how it works, meaning there should be a unique key which acts as the expression and only an evolution of the true the cache will happen.

And similarly the next time the same key comes in with the combination, that is when the response will be retrieved and then how to invalidate the cache, a particular cache element or the whole cache, et cetera. Now, let us discuss in more detail. If you remember, we also said that the Http caching is mostly applicable for the Http methods like Get and Head, et cetera.

Correct? We said only for such API methods or Http methods it is better to use and there is a certification rate questions as well and all. So let us discuss bit more in detail on why that rule is there and what is it about. So, these Http methods when it comes to caching are called Safe Http methods. So the safe Http methods are ones that do not alter the state of the underlying resource. Okay? So that means the Http responses to requests and using same Http methods may be cached.

So what do we mean by not altering the state of underlying resources? So, if you know the Http works better, the methods like Get, Head, Options, these are all kind of retrieve or read only related Http methods. Okay? So Read only means they do not change the state of the background resource or underlying resources. They are only reads get head options, et cetera. But if you talk about Put, post delete this kind of particular Http methods, they may alter the state, delete may go and delete something, put may update post, may add something.

So they are something which will change the underlying state. So the safe http methods for caching are get head and options. Okay? Remember, these three get head and options. So these are the ones that guarantee that they do not alter the state of the underlying resource. But remember, this is not implicit behavior. Meaning just because if you use Get, Head and Options does not mean that the underlying resource is not altered. This is the respect we have to give and follow the pattern of APIs and implement accordingly. Okay? See, technically if you use a Get method, pass some details in the query parameter and inside the AP implementation, you read the query parameter and if you do an insert or update in the back end resource, it will still work, right? Technically it will work because no one is going to know what’s happening behind the scenes the specification.

The rest is to deliver what is given in the particular URL, using query parameter on a particular method, et cetera. Respect to all those things, route the traffic and on a particular resource as requested, the data will be submitted and on the resource inside. Whatever implementation we do is up to the implementer. So if we misuse it and say on a get related Rest resource we read the query parameters and do insert and alter the state, it is wrong. Okay? Technically it will work, but it is not ethical behavior of the Rest APA. So all these APA rules should be honored and should be fall under the responsibility of the APA implementation to implement the methods correctively. Get head options should be always used for resources that does not or never change the state of a resource only and use post delete accordingly for respect to definitions of semantics.

Okay? So this is rule number one. You have to honor those, then you can having these kind of rules only makes the assumptions true because tomorrow only developers will know what is implemented, right? Architects like us and all will not know what is happening in the appointment decision. So we make a lot of assumptions that it is a get resource. Let us add Caching and we may do it. But background there might be a developer decision that it is doing an insert so it will be a shocker lateral point of time. So these should not be surprises. Okay? So always make sure people respect and AP implementation takes the responsibility of honoring the safe Http methods. Now, what are the different Http out of the box facilities that are related to Caching?

Comes handy when implementing caching for the APA invocations. Okay, so these are only benefit for the Http based APIs which are mostly Rest APIs. So only APA functionality exposed device safe Http methods once again may return the cache the Http response. Okay? Now Http natively defines some rigorous caching semantics using the Http address, okay? This feature is therefore immediately available to Rest APIs but not for like discourage other APIs because they are non Http based, right? Say, what are those? Number one, cache control two, last modified. Third, e tag. Fourth if match if not, match if modified since. And last one is age. These are some of the inbuilter out of the box Http related facilities that come handy, okay? We can make use of this with respect to caching the APA as well. So the Caching requires basically two things, right? One is the storage management.

Second, in manipulation of Http request and response headers in accordance with the Http specification. Okay? So since this Http based caching is communicated by Http headers, it should be documented in the again Ramble definition of each API and published, okay? Otherwise the clients will not know that they are going to receive these headers in the response like this cache control, last modified, Etag, et cetera, et cetera. If this has to be sent back in the response or received in the request. The same has to be reflected in the RAML no matter what. The more better documentation, the more successful will be your API. Spend the most of your time documenting and gaining the client confidence. Okay, so again, who plays the key role here, particularly C four? E, because I’m saying particularly C four, it doesn’t mean if you are going to be an LLB team member, you can ignore this and blame C four.

You know, it is everyone’s responsibility. But particularly C four should be actually more concerned and make sure these kind of things are reflecting in the RAML, okay? When such sensitive things like Caching are going to be applied on the APA resources and all, they have to be made aware and also told that okay, we are doing this, we have added to the RAML, please verify kind of. Okay, so this Caching may occur in the APA client or in the APA implementation side and any network component such as a Caching proxy between the APA client and the AP implementation.

So if it is a implementation, then mule applications can actually have a facility called Caching Scope and Object Store and all so they can be used for the Caching purposes. So if a mule again, even if API client is also mule application, say if mule is acting as a client calling some external API, then also we can use the same Caching scope. Doesn’t matter. Okay, so rest. I’m saying there is a facility in the mule software. Okay, so these headers can be set like okay, last modified is like when was the cash last put? So that the clients can know in the Http response header, okay, it’s last modified if it is a date or 3 hours back or 4 hours back or whatever, then they know that okay, how latest the cash value they are receiving.

Similarly if match, if not match if modified since they are like tags, they can send requests something to say. If match means if this condition is matched then only do if it not match then only do something like that as is like how old the cache element is. So these hydrosonal should be implemented accordingly in the implementation part of the client to implement client side part. Okay? So this is how little more details you need to know about the Caching, the specialist safe methods and the inbuilt Http headers that are handy in tracking or controlling the cache behavior. Okay? Happy learning.

7. API Retries and Idempotency

Hi. In this lecture, let us discuss about various ideimportant Http methods and how retry should be implemented for certain methods currently following or honoring the Http methods. So generally all the Rest TPS use Http based protocol. It’s a known fact and all of you know that, right? And the Http request send response may be lost due to a variety of reasons, okay? It is software, anything can happen and it’s definitely our network. So there is chance that either a request or response may lose. So here the thing is if a Http request is lost, then it can be retried, okay? From the client side, fine, all right? No issue. But if a Http response is lost for a request that is accepted by the API implementation or provider side, then retrying the same request from the client may cause duplicate processing, okay? Because the client have not received the response.

So under the assumption that the client has to retry, whereas the processing on the AP implementation side may actually finish the processing but only the response delivery might have failed due to some network issue and permitted issue. So this may cause duplicate processing. So with respect to this aspect in general, I’m not talking about rest http methods itself like however, we discussed about the caching that http itself has some rules with respect to caching and the http methods the safe http methods the gap should be implemented only this way should be this way so that they are safe, they’re honored. Same way we should honor some of the Http methods and their meaning in the Http world to make sure.

That these retrace are correctly done and we can still keep the semantic of those methods same even in the rest world and how we can give the confidence to the APA clients. Okay? So like however there are safe methods for caching same way there are some methods called item potent Http methods, okay? You may have heard this term item potent. We have been hearing from our education right from childhood item potent is exactly one kind of thing, exactly one’s processing. So item potent Http methods are ones where Http request may be recent without causing duplicate processing. That means Http methods which are ident may be retried from the APA client side without any assumptions, blindly like that and still it will not cause any impact.

So the such methods are the get head options put and delay. So these methods are the Http standards wise itself item potent Http methods. So get head and options are straightforward as we discussed before, they are kind of read only type, right? So it is obvious they are idempotent. Obviously you can read any same resource any number of times, but if you see put and delete these methods right, are only the two methods which may change the state of a resource among this file, okay? Get headwind options are read only. So it is always evident that they are very important potent. But put and delete may change the resource.

Delete, delete something, put me inside something. So they are not safe by default. Correct. So again, the API implementations, what they should do here is they have to make sure that when implementing any resources which are put or delete, then it is responsibility of those every API implementation to implement this put and delete method such way that they do not alter the underlying resource. If that put or delete was already successfully processed, we will discuss how is it possible, but it is the responsibility of API implementation side only in the rest API world, okay? Because the differences were given by Http standards, fine. But end of the day, like we discussed before, what happens after the request comes to the implementation side can be anything. Even if the standard says that someone may implement put as a non. Admitted, okay, it may necessarily do duplicate things. But if we talk a standards level, it has to be responsibility of a limitation to make sure to respect the Http standard, to honor them and treat put and delete aside important only.

Okay? On the other hand, post and patch, there are other methods as well, right? We see most commonly post Rest resource also. So post and patch are not idempotent from Http standard. Even Http standard itself doesn’t say they are idempotent or not. Okay? They are not idemportant only, so they’re not safe by default. So if Http responds to a post or patch request does not reach the APA client, then the APA can in general not send the Http request without causing duplicate processing. Okay, so then the story is different. So for posted patch, the agreement can be such a way that it is at the risk of the APA client whether to do the retry or not.

All right? Because we are clearly telling asper standard that we do not guarantee v means the APA implementation do not guarantee that the post and the patch is idem potent. Okay? So we may have some different way or different kind of agreement. In general, do not retry for the post and patch from the AP client side just to erase a support incident.

And the team will take a look and see. Okay? If it is failed before processing, then we can reprocess internally in the implementation side, or if it is already processed, then we will give you an acknowledgement. Okay? So API clients should not be generally trying unless there is a clear agreement that they can retry. They should not be retrying for post and patch, whereas for put and delete, even if it is not specifically mentioned, they have to make sure that implementation takes responsibility to make them unique.

So now the second question comes is, okay, fine, we can try to do that, but how do we generally guarantee that it’s already processed or not? How do we know implementation side because it may get processed ten minutes back. Now, is a client tried again for the put or delete then how would we know? So again the state comes into picture if you are using mule three run times. Mule three nine attacks are below, then mule applications acting as AP implementation may make use of an Idempotent message filter. Okay? There is something called it important message filter in the processors you have. So you can mule three runtimes can make use of that to aid the implementation of this requirement. Okay? It’s out of the box and it will by default make use of the hash message hash. Okay, from the Http request that comes, it converts into a hash including Http red headers body, everything and maintains the hash. And next time when the similar request comes after a certain number of time before the TTL or whatever, if the hash matches, then it will be safe.

Okay, rotor but it is already processed so it will kindly ignore or simply gives a success response or something. But it is important. But what about the non mule three run times? Okay, so how we can do it generally, how does an AP implementation in general whether three or four can decide if Http request was already received and must therefore be discarded or not, is like one approach is to treat all requests with identical content. When it’s a content, it means the Http request body and the relevant request headers are identical. Okay? So again, this is somewhat similar to the default implementation we discussed about the IDE important message filter for those mule the run times where the decision is based on the hash of the mule message body.

So same way, because it is not there for the non mule times, we can have a custom code to hash the content which is request body and the relevant request headers and compare it, put it in a state and compare the subsequent request if that has his messaging with any of them. Okay? This can be implemented for put or delete. Okay? But the only problem is this approach may prohibit identical put a delete request from being processed at all, which may be problematic sometimes. Okay, see the thing is the problem is like say we have done a delete resource on a particular client, for example, or I don’t know current example, but it’s a particular resource. Now after a minute maybe there was another update or an insert with a similar data.

Okay? Now again, say we want to delete. So this is genuine delete because in the middle there was an inserter update which created the record back again. But now because of this particular full comparison, the logic may think that it’s a duplicate request and it may completely ignore, right? So there is another way. So a common refinement of this approach which discussed is therefore to require the API client to generate a unique request ID and add that to the Http request. So this is the most suggested approach. This will avoid confusions or assumptions. The previous one has to cater for a lot of scenario that okay. The middle there should be no inset update then only views. It is kind of for simple scenarios, it is okay. For complex things, it is definitely a problem creator.

So that is the reason even on the mule four or non mule three runtimes, even mules are removed that item potent message filter. Okay, so the better approach is to agree or make it a part of contract with the API clients itself, saying see, we can make sure that the potent delete can be item put in. But we need some help from you, which is to generate a unique request ID every time before you click a request. Okay, so you know, maintenance logic, you can have UUID, Guid, whatever, just create one and put it in the request. That is a simple agreement. You can make it as a part of trite or something. Remember, we had a transaction IDs try it right?

Similar way, you can have a request ID as well as a try in your Ramble and enforce it. Make it mandatory so that you are bound to pass it. Okay? Now, what the logic can be or how the logic can be enhanced. So if the APA clients again resends the request, it must match the same request ID. Okay? That is the agreement you have to do with the APA client. So if you are retrying, if you tell that, you have to tell the APA client that if you’re retrying a request, do not generate a new request ID, use the same request ID used before, okay, which was original request, then the implementation will know that. Okay, this is the same request. Because this time we won’t be doing any hash and storing in the state or object store or database.

We will store just the requested in the database. Now, when subsequent requests come, if we match get a match for the requested against the existing data store, object store or a database, that means it is a duplicate request, so we can handle it as a safer way. But if we do not get a match, it is not identical to the request IDs we got before, then it means it is a new request. It can be processed. So this is a better clean way to deal the retries.

Okay, so this is how the best patterns or architectural patterns recommended with respect to retries, as well as to honor some of the Http item methods so that both combination will help to achieve cleaner rate raise and all. Okay, without assumptions that who will perform retrace, who with said clients have implemented inside. All right, happy learning.

• Category: Uncategorized