Can Azure API management cached based on request payload? - azure

Is it possible to use cache based on a key in the request payload?
Eg. let's say we got a json or xml request payload where one of the elements is CustomerId.
Would it then be possible to cache based on CustomerId?
Thanks

I hope I understood your query properly and am not too late. I think you want to cache only when 'CustomerId' is present in the input OR it contains a certain value.
You can refer to the samples given in the foll link
https://azure.microsoft.com/en-us/blog/policy-expressions-in-azure-api-management/
It will help you to write policy expressions to check the presence or value of a particular field. Then you can cache or ignore based on that.
On a side note, Custom Caching is also something cool to check
https://learn.microsoft.com/en-us/azure/api-management/api-management-sample-cache-by-key

Related

Is it bad practice to include id of object i want to delete in url query?

Im wondering if its bad idea for me to send DELETE Request on server endpoint
lectures/remove?id=${lecture._id}
I am aware that DELETE Requests shouldn't include req.body.
Does it matter if i pass information via params or query? or is there perhaps better way to sending info as delete request in order to delete some info from db?
Feels like just matter of semantics.
Thanks for answers in advance.
In general, if you have a RESTful API, and you want to refer to a resource you use URL parameters as you want to identify that single resource.
So you would have something like
DELETE /lectures/:lectureId
As it's a single resource of lectures.
However, you may want to delete multiple resources and in that case, it is a common practice to use query parameters
DELETE lectures?id=LECTURE_1&id=LECTURE_2&id=LECTURE_3...
So the "best practice" that you might be missing here is that you should use nouns instead of verbs in endpoints as you are dealing with resources:
Keep URLs verb-free
Avoid actions — think about resources
Unless you design your API in a way that you trigger a deletion task/process by calling this endpoint then you can challenge this recommendations.
See more:
http://opensource.zalando.com/restful-api-guidelines/#delete
RESTful - What should a DELETE response body contain
https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/
https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design

Modify a CloudFront request before logging?

I'm building an ELK stack (for the first time) to track end-user REST API usage for a CloudFront distribution (in front of an S3 origin). Users pass a refresh token as part of their request and I was hoping to use this token to identify which users were making which request. Unfortunately, it looks like CloudFront access logs are missing some header information (particularly Authorization/Accept in my use case). This leaves me with three questions:
Is there a way to tell CloudFront to log additional items? It appears the answer is no.
As an alternative strategy, I tried modifying the request object with lambda#edge (in Viewer Request) to move the header information into the query string (so that it would get logged) but any manipulation in lambda#edge does not seem to be reflected in the log. (though it is reflected in the Origin Request function). Should this be possible?
If doing what I want is impossible, I think the alternative approach is forgo CloudFront logs completely and just fire an http request to logstash with every user request, but I feel like this could be easy to overload.
Thanks
After a few days of research and reaching out to Amazon, I was finally able to answer my own questions:
CloudFront logs can't be customized, they are what they are.
See 1.
It turns out that customization is the wrong approach. What I really need to do is aggregate two separate logs that have the information I need into a single logstash entry. It turns out that the Viewer Response lambda#edge function contains a requestId property (actually event.Records[0].cf.config.requestId) which matches the CloudFront log x-edge-request-id column. So while I haven't finished implementing it yet, these two columns can be used in the logstash config for aggregation. I just need to make sure I set up a Viewer Response event that logs out a consistent format that I can then part with logstash. I'm using the logstash-input-cloudwatch_logs to retrieve teh cloudwatch logs.

How can I update the multiple records using PUT in Web Api in one Call?

How can I update the multiple records using PUT in Web Api in one Call?
For updating single record the URL would be
http://localhost:4211/api/AuditChecklist/{id},
but what should I pass in place of {id} for updating multiple records in one call?
Your API would need to support this, and it doesn't look like it does. Your best bet might be to employ a for loop in the client code calling the API. Or you could write your API to accept a JSON body with a variable length hashtable containing the values to update and their new value.

GETting a document within a Document Update Handler

Is it possible to query (GET) a document from within a document update handler in CouchDB?
I have written a simple document update handler in CouchDB 2.0 to accept a POST from a third party (CognitoForms). This works fine, and I take the ID from their JSON payload and use that as the doc _id.
You can then specify an 'update' URI in CognitoForms, so I could create a new update handler or use the same one. However, in CognitoForms:
The update does a POST rather than a PUT
There does not appear to be a way to send any query parameters
As the ID for the document which needs to be updated is within the body, I could use this to query the database for the document, get the _rev, and return the payload with the _id and _rev to perform the update. However, I simply don't know if I can do such a query within the update handler. I feel like I am either missing something obvious, or there is a very good reason that I wouldn't be allowed to do that.
Thanks very much
edit: I should add that I understand I could create a small application to parse the request before forwarding on to couchdb, but I was interested to see if I could implement this in couchdb only to understand how far I can get without another layer!
In your particular case, it's quite hard to do this. A document update handler is basically a pure function that gets the data it needs and returns a response, but it has no way to reach out into the database.
If you add a doc id to the url, the update function gets the doc from the database as a parameter. For details see the CouchDB docs for update functions.
The way to a possible solution is to use a rewrite in CouchDB in order to extract the id from the body. In CouchDB 2.0, a new way for rewrites as functions has been introduced.
For pushing the limits, using a rewrite function for this sounds like fun. But for a production use case, it's probably easier and more maintainable to create a small node.js app that parses the body.

Pass metadata along seed urls with Nutch 1.X REST APi

I'm currently trying to include the seed url in the data indexed for each url in my search backend (currently ElasticSearch).
I've seen in this previous question that metadata could be passed with each seed, which could suit my need. However, I'm using the REST API to create my seed list, and it seems that metadata aren't allowed in the seedUrls parameter.
Has anybody tried to do this with the REST API?
Is there another way to achieve this?
I thought I could write a custom IndexingFilter to add the seed URL in the NutchDocument to be indexed, but at this point, the seed URL is not available from what I've seen.
Thanks in advance!
At the moment the REST API doesn't seem to support handling associated metadata. I believe that this doens't require such a great effort to accomplish, basically we just need to handle the JSON payload and customize the corresponding entity SeedUrl to hold the metadata and of course customize the writeToSeedFile method.
Although your approach of writing an IndexingFilter wouldn't work. The seed URLs are injected at the very begining of the crawl life cycle, and the IndexingFilter are only responsable of choosing what gets indexed into your storage.

Resources