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
Related
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
http://localhost:4200/product-list?gender=2&category=4
http://localhost:4200/product-list?gender=2
http://localhost:4200/product-list?category=4
i want to use one backend controller for the endpoints.
can i do that? i tried but with no success. (using angular)
What exactly did you try with angular? The backend controller? Angular is a frontend framework.
However, you could indeed have one single controller (e.g. ProductController) for your endpoints. I would suggest implementing a "getProducts" method that can be filterable. That way you can use single endpoint and provide optional filter options as needed.
I may not understand your question entirely, so please stat otherwise. But, Yes. You have one endpoint stated above, with different query params. Depending on the different query params (their value or even if they are present), your singular endpoint can do something different.
So your endpoint is
http://localhost:4200/product-list
This endpoint (which there is only one), can have as many query params as you like. As per the response above, Angular does not handle this, this would be some backend functionality for your end point, to read the request, and based on what query params are 'found' then trigger a different response.
Summary
I am seeing a lot of contradictory architectural examples of a REST API in my work and keep getting different opinions on the subject.
I am familiar with the principles of REST and seeing as each endpoint points to a resource followed by a verb such as /project/create project/123/read.
Following the MVC pattern assuming I have a controller that is responsible for updating a project resource:
router.put("/project/:id/update", ProjectController.put)
First question:
Should this route be responsible for all updates to this resource, in example, assuming different features on my client like marking a project as finished or changing it's title are separated and might not have anything in common for the user. Ending up with the route described above, or should there be something like this:
router.put("/project/:id/mark-as-done", ProjectController.markAsDone)
router.put("/project/:id/update-info", ProjectController.updateInfo)
Second question:
Assuming I want to create a notification resource if a project is created/updated/deleted. Since the notification is a resource on it's own I am not sure how to go about this, but what I assumed and was taught is to use another callback:
router.put("/project/:id/update", ProjectController.put, NotificationController.create)
Third question:
Could I use the same controller to read all resources or just one, for example:
router.get("/project/read", ProjectController.get)
router.get("/project/:id/read", ProjectController.get)
Making the logic in the controller method determinate if it will return all projects or just one. Or should it be separated into different methods?
I would define APIs like this:-
CRUD for Project entity
create- router.post(/projects)
update:- router.put(/projects/:id)
delete:- router.delete(/projects/:id)
read:- router.get(/projects) and/or router.get(/projects/:id)
You can define all above routes in ProjectController.
Regarding Notification entity you can define as follows
read:- router.get(/projects/:id/notifications)
The same can be applied to PUT, DELETE, POST
Here is a good article defining rest guidelines https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/
I have a resource /cars and the endpoint in angular defined as
$resource('/cars/:carsId');
to GET all cars and a specific car.
At the server level, I have also added a middle-ware to check that carsId is always a valid MongoID.
Now I want to define another endpoint to GET all redcars.
My initial though was to add another resource like
$resource('/cars/redcars');
but this does not work since at the server level, my middle-ware will through an error because redcars is not valid MongoID.
My question is what is the best approach in this case ?
I can add a logic at server to check if the MongoID is invalid, but, if the value is redcars then return all redcars.
or there is a better way of doing this.
Thanks
pkpk
Typical patterns are:
use query parameters, as in, /cars/search?color=red
use /cars/types where the /cars/types/:color can be applied
An excellent resource for design patterns in API design is the Apigee API guide. NOTE: I am not endorsing Apigee by recommending their guide; I simply find that this ebook has many useful patterns collected in one place.
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.