Let me start off by saying this whole php pseudo-library is very likely to be entirely scrapped and rebuilt in the near future. It was more a basic proof of concept base, that wasnt updated due to resources constraint.
While it looks like using the PURGE verb seems easier, there are technical differences from using that method vs going through the API endpoint. Things like rate limiters, and queuing are done differently, and as we move toward allowing authenticated purges, that would facilitated by the API.
Also keeping it through the api keeps the code pattern the same across the functions. There is a possibility that we may begin generating these libraries pragmatically as the API expands, so keeping things in 1 style helps this happen.
Additionally, we may eventually stop using the PURGE method, but the /purge/ endpoint will stay consistent, as that is what APIs do, hide the technical changes from the front side.
The last thing to consider, is that because PURGE isnt a standard http verb, there may be some technical issues for things like proxies that may not know how/what to do with it, and may drop it. While this is rare, we should aim to keep the code as open to as many of users as possible with the least possible issues by keeping it as a POST.
I'll confer with a few of my colleagues before making the final close/merge choice on this, but I did want you to know it is a good patch, just maybe not one we want to do right now. :+1:
Let me start off by saying this whole php pseudo-library is very likely to be entirely scrapped and rebuilt in the near future. It was more a basic proof of concept base, that wasnt updated due to resources constraint.
While it looks like using the PURGE verb seems easier, there are technical differences from using that method vs going through the API endpoint. Things like rate limiters, and queuing are done differently, and as we move toward allowing authenticated purges, that would facilitated by the API.
Also keeping it through the api keeps the code pattern the same across the functions. There is a possibility that we may begin generating these libraries pragmatically as the API expands, so keeping things in 1 style helps this happen.
Additionally, we may eventually stop using the PURGE method, but the /purge/ endpoint will stay consistent, as that is what APIs do, hide the technical changes from the front side.
The last thing to consider, is that because PURGE isnt a standard http verb, there may be some technical issues for things like proxies that may not know how/what to do with it, and may drop it. While this is rare, we should aim to keep the code as open to as many of users as possible with the least possible issues by keeping it as a POST.
I'll confer with a few of my colleagues before making the final close/merge choice on this, but I did want you to know it is a good patch, just maybe not one we want to do right now. :+1: