[wp-trac] [WordPress Trac] #43744: `WP_REST_Server::EDITABLE` should not contain POST

[WordPress Trac]

#43744: `WP_REST_Server::EDITABLE` should not contain POST
--------------------------+------------------------------
 Reporter:  soulseekah    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  REST API      |     Version:
 Severity:  trivial       |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by soulseekah):

 Thanks for the rapid response. A POST request is expected to to create new
 resource, which I certainly don't want to give the impression of allowing.
 A POST to a collection is fine, we have `CREATABLE` for that. But adding
 `::EDITABLE` to a single item resource would add `POST` implying that
 resources can also be created.

 So I can't give my endpoint the `::EDITABLE` flag, and instead have to
 write `array( 'PUT', 'PATCH' )`, something annoyed me a bit and broke the
 flow. Trivial, and easily fixable, especially if they're converted to
 arrays, in core you would change all instances of `::EDITABLE` to
 `::EDITABLE + ::CREATABLE`.

 Again, just being pedantic, the world doesn't have to stop because of
 this. And I may be mistaken regarding the POST, but here:

 https://en.wikipedia.org/wiki/Representational_state_transfer#Relationship_between_URL_and_HTTP_methods

 I guess a `POST` request to a single Taxonomy item would be equivalent to
 creating a new Term inside that Taxonomy. But a `POST` to a single Term
 wouldn't make sense, no? I understand that the three verbs for core
 endpoints are aliased, and okay, but if I don't want a POST to be
 available and working for robustness, documentation purposes I can't use
 `::EDITABLE` in its  strict sense.

 Hope this makes sense.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43744#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform