I am using rest api. I want to delete all pushes, but I don't know how to write the query.
I know how to delete a specific push.
delete $apiUrl/pushes/$pushId
What I want is to delete all pushes for that user.
$apiUrl/pushes?owner=$ownerId/ ???
thank you
I would recommend 2 approaches
Do it in a non-rest way by sending a custom JSON object containing the ID's marked for deletion. Reference
Mozilla Storage Service SyncStorage API - to delete multiple records using REST. Reference
REST isn't the only way to solve any problem. “REST” is just an architectural style and you don't have to adhere to it (but you lose certain benefits of the internet if you don't). I suggest you look down this list of HTTP API architectures and pick the one that suits you.
Related
I have a project to maintain the user and his/her project allocation records. The project exposes REST APIs to support user/project CRUD operations.
The REST endpoints are designed to support backward compatibility using REST API versioning so that any new changes in the REST API should not affect the existing consumer of that API.
I have the below use case where I need suggestions for the best approach:
At first, the business requirement was that a user can be deleted irrespective of his/her allocation to some project and hence the REST API to delete the user was created with version v1 to support this.
But then there was a change in the requirement that a user cannot be deleted if he/she is allocated some project.
This is a change in business validation. Should I create a new version(v2) of user DELETE REST API to support this business validation or I should add this business validation to the existing version(v1) of user DELETE REST API?
My viewpoint:
If I will expose two versions of the user DELETE REST API then the database can have records with deleted users with as well as without project
I would argue that this is more of an implementation detail of the backing store. In all likelihood, the storage mechanism for both is almost certainly the same.
I would not change the DELETE API nor version it because the contract is 100% the same over the wire. A client has no idea how it's implemented behind the scenes; they're not supposed to anyway. The implementation needs to change such that a DELETE always results in a soft delete after some point in time (e.g. when you publish the new version). If you version DELETE you also open things up where clients can do things you don't intend; for example, triggering a real deletion by using a specific version of the API.
The thing that needs to change is how the older APIs deal with all of the other supported methods such as GET, POST, PATCH, and so on. The older APIs should yield 404 for a soft deleted resource (implying that DELETE was permanent). POST is probably the most unusual case. This could return 409, but that implies the resource exists or it could result in an update that also undeletes the existing resource. This API would likely even continue to return 201, implying the resource was created when it was really just updated in storage.
Remember that Representational State Transfer is just a representation of your business logic. Keep the APIs the same (and thus clients from breaking) and adjust the implementation to adapt to new rules. The DELETE API is unchanged (and usually version-neutral). Clients don't know what the man behind the curtain is doing. If things continue to behave the same over the wire, clients are none the wiser.
I hope that helps.
Hey guys I wonder if anyone can help with this.
Now I am facing a problem at my company. We are developing a Magento 2 Community multistore for our customers.
The idea is to have several stores in the same Magento 2 installation, where each store is for each independent company. The problem is the integration with our ERP system. With the API REST we have full control in the installation, even if we are not with the admin master credential. if we run commands like this in postman: https://magentostore.com/rest/V1/orders?searchCriteria
we have all the orders in installation, all stores. So the companies with their credentials would have the same control and it is a very bad problem of security. The stores would have access to data from each other.
We have tried extensions for advanced permissions like Aitoc and Amasty but it's only works at a frontend level and does not take any effect in API REST. We know that Magento was not made for this kind of thing so my question is:
is it possible to change the API REST to filter the queries by store? and where can I find these API REST queries?
I'd thank you so much.
So you can override api calls using webapi.xml file in your module, Just point it in your service interface and change acl if you want. In your service interface inject the original one and add some your filter before calling original.
The second approach to write a plugin on OrderRepositoryInterface and add filter there (but first solution is better because this service is used not only in api so you may do not want to restrict all calls)
Im working on a web service that i want to be RESTful. I know about the CRUD way of doing things, but I have a few things that im not completly clear with. So this is the case:
I have a tracking service that collects some data in the browser (client) and then sends it off to the tracking server. There are 2 cases, one where the profile exists and one where it does not. Finally the service returns some elements that has to be injected to the DOM.
So basically i need 2 web services:
http://mydomain.tld/profiles/
http://mydomain.tld/elements/
Question 1:
Right now im only using GET, but im rewriting the server to support CRUD. So in that case i have to use POST if the profile does not exist. Something like http://mydomain.tld/profiles/ and then POST payload have the information to save. If the profile is existing i use PUT and http://mydomain.tld/profiles// and payload of PUT has data to save. All good, but problem is that as far as i understand, xmlhttp does not support PUT. Now is it ok to use POST even though its an update?
Question 2:
As said my service returns some elements to be injected into the DOM, when a track is made. Logically, to keep it RESTful, i guess that i would have to use POST/PUT to update the profile and then GET to get the elements to inject. But to save bandwidth and resources on the serverside, it makes more sense to return the elements with the POST/PUT to profiles, even though its a different resource. What are your take on this?
BR/Sune
EDIT:
Question 3:
In some cases i only want to update the profile and NOT receive back elements. Could i still use same resource and then using a payload parameter to specify if i want elements, e.g. "dont_receive_elements:true"
On question #1, are you sure that xmlhttp does not support "put"? I just ran http://www.mnot.net/javascript/xmlhttprequest/ on three browsers (Chrome, Firefox, IE) and according to the output, "put" was successful on all browsers. Following the information on http://www.slideshare.net/apigee/rest-design-webinar (and I highly recommend checking out the many Apigee videos and slideshows on restful API), "put" is recommended for the use case you mention.
But you may be able to avoid this issue entirely by thinking a little differently about your data. Is it possible to consider that you have a profile and that for each profile you have 0 or more sets of payload information? In this model the two cases are:
1. No profile exists, create profile with a POST on .../profiles/ Then add elements/tracking data with posts to .../profile/123/tracks/ (or .../profile/123/elements/)
2. Profile exists, just add the elements/tracking data
(Sorry without understanding your model in detail, it is hard to be very precise).
As for question #2 - going with a data model where a profile has 0 or more elements, you could update the profile (adding the necessary elements) and then return the updated profile (and its full graph of elements), saving you any additional gets.
More generally on question #2, as the developer of the API you have a fair amount of freedom in the REST world - if you are focused on making it easy and obvious for the consumers of your API then you are probably fine.
Bottom line: Check out www.apigee.com - they know much more than I.
#Richard - thanks alot for your links and feedback. The solution i came down to is to make the API simple and clean as you suggest in your comment, having seperate calls to each resouce.
Then to be able to save bandwidth and keep performance up, I made a "non-official" function in the API that works like a proxy internally and are called with a single GET, that updates a profile and returns an element. This, i know, is not very restful etc, but it handles my situation and is not part of the official API. The reason i need it to support GET for this i need to call it from javascript and cross domain.
I guess i could have solved the cross domain by using JSONP, but i would still have to make the API "unclean" :)
I have a REST service that serves Invoice functionality, for example I can create, update and delete an invoice via the REST service.
However I now need to have functionality to split an invoice into several new invoices, i.e. the method needs to create x invoices based on one invoice, and then delete the original invoice in one transaction.
I also need a merge method that does the opposite, i.e. multiple invoices merged into one.
How do I create such architect the RESTful way?
We had a similar issue where we wanted to merge 2 resources. After a long debate we decided that a consumer would POST a merge request resource which contained the 2 resources to be merged. Then after looking at it we decided that there was no need for both the complete source and target resource and instead a POST of just the unique identifier was sufficient. We didn't make the merge request with just the 2 ID's come in the body. It was easier to represent in a URL so that's what we did. The response from the POSTing of a merge request is the merged resource.
I guess I'm not a REST guru enough to tell you this was a good strategy or not, but for us it was a simple solution so we went with it.
When you say that want to implement this functionality in "one transaction" I assume you have already determined that you should combine generation of the new invoices and deletion of the old one, into one API call; which is the correct approach. With web services you do want to reduce chatter and there is probably some business logic on how this functionality will generate the new invoices and delete the old one. So I am assuming when you ask how to architect this in a RESTful way you are wondering which HTTP verb to use (i.e. GET, POST, PUT or DELETE) for this new API method. Usually these verbs map to CRUD type operations in the following manner:
Create -> POST
Read -> GET
Update -> PUT
Delete -> DELETE
So which verb to use when your function both creates and deletes records. A general rule with REST API's is if there is not a clear mapping to CRUD then use POST if there is a change to the server state and a GET if you are just returning information that does not change the server state. So in this case I would go with a POST.
If you are looking for additional guidance on architecting this please be more specific in what you are looking for and I will try to help.
I would do something like,
POST /InvoiceSplitter?sourceInvoiceId=99
and
POST /InvoiceMerger?sourceInvoiceIds=101,87,23,45
I have a client-side interface that allows the user to perform multiple edits against a tree-like outline. I consider the aggregate of the records making up that outline, in totality, a single resource (/outlines/39) even though its parts could be accessed as separate resources via different URLs.
The problem is the user can edit existing nodes in the outline as well as add new nodes to the outline. Normally, when you edit something you PUT its changes and when you add something new you POST it; however, in some cases you'll want to wrap all the changes--including both adds and edits--in a single transaction. What are some practical ways people have handled this?
Even though the outline already exists and a PUT seems appropriate, the embedded adds violate the idempotence of the PUT. I'm not sure that POST seems appropriate either. For design purposes, I have decided not to save each discrete update the user makes though I guess this offers one solution. Still, there must be others who have dealt with my issue or have ideas about it.
Is there any way you could make the add idempotent? E.g. if nodes had a natural key, then when the client tried to add a node a second time you could do nothing.
How about: make a new resource: /outlines/39/transactions, and POST your transaction to that resource, e.g.
POST "addNode=node1, addNode=node2, editNode=node3,newName=foobar" to /outlines/39/transactions