Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I really don't understand why this was never enabled. It seems like it was purposefully left disabled with little to no explanation as to why.
Anyone can create a script that can login and then POST via a normal request using the fields from the form, for instance.
Enabling this would just make the process easier and consistent with the existing GET requests via the API (e.g. no extra "manual POST request" boilerplate code).
Comments
Comment #2
markhalliwellComment #3
MixologicIt was purposefully left disabled, and the explanations are in the issue that was being used to enable it in the first place:
#1710850: Deploy RestWS for D7 project issue JSON
https://www.drupal.org/node/1710850#comment-8614017,
https://www.drupal.org/node/1710850#comment-8858831,
and in particular https://www.drupal.org/node/1710850#comment-9033549
I think we are still lacking those same assurances that we didn't have then, and we haven't yet set aside/prioritized the time to fully vet this path. RestAPI had a security release *just today*, which underscores the need to verify that there are not some unintended consequences.
Additionally, the restws API doesnt have any of the ancillary features that would make it robust - particularly something like rate limiting and abuse monitoring, which are also some things we would like to have in place before offering up an endpoint to automated tools.
Which brings us to Policy: We also have to define what is and isnt acceptable via the api, and write it down so when somebody does do something distasteful with our endpoints, we can tell them to stop and that they're violating our policy.
In any case, mostly this hasn't been done yet because other things have been higher up the priority list.
It's still definitely a good idea and would be an exciting feature to have on Drupal.org
Comment #4
markhalliwellFair enough. I simply didn't think to go parsing through an old issue. I was more so referring to what https://www.drupal.org/drupalorg/docs/api says: "Only read access is allowed." and the lack of an explanation.
And d.o itself does? I think these are two different issues/problems; one that could be solved on a infra/server level before it even reaches the site (which I thought already existed, but meh).
This isn't just about or for "automated" tools.
I've been toying around with the idea of posting a user's patch review comments on behalf of said user to eliminate unnecessary additional steps/clicks for #1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features.
Can it be done via the existing form currently, sure, but that really isn't the point. DOM markup can change over time and selectors get broken which invariably breaks said functionality. I'd prefer that it just posts as JSON data via the API instead.
There's also the idea of desktop level applications/tools that login on behalf of the user to do things only based on human input (e.g. drush_iq) which requires a human to actually invoke said commands.
Granted, I suppose one could create a wrapper script that spams said commands, but then again... one could do the same thing with cURL or wget.
Sure, I get that.
That all being said, I guess this issue should be postponed on the following parent which will define said policy.
Comment #5
MixologicI did do a quick glance through the module and the issue queue to see some of the state of things, and I see issues like this (#1720602: Creating nodes with POST should work without bypass node access permission) and am somewhat unsure as to the state of how well restws supports the kinds of authentication and authorization that we need.
One of the other things that would make this more robust is to follow other API best practices and issue secure tokens to users to utilize the api for authentication and authorization.
Restws really only offers basic http auth (which we obviously cannot use) and http cookie based auth. cookie based auth is really less than ideal - It *would* allow you do to the kinds of things you are proposing, like posting comments without having to use the comment form because you are in a browser already and presumably have access to the users cookies. However you could also accomplish those things with a roundtrip through the backend ( without using the existing form, just using hooks internally)
But for other external tools, its really not great to ask people to store their passwords in other tools (desktop applications/tools) like drush etc. That's why its pretty universal that every service that offers an API allows you to go to a config screen and generate an api token, and even restrict permissions on that token to do only certain things.
Comment #6
markhalliwellSo, I really don't understand why RestWS was implemented on d.o in the first place. I've skimmed through some issues, but cannot seem to find why it was chosen over Services.
---
From my viewpoint, it was implemented just for the sake of being able to append ".json" to existing resources.
Which, co-incidentally, isn't how d.o operates in the first place (everything is prefixed with
api-d7).As with anything that "just exposes", it inherently comes with a trade-off of less dev work, but also with less security and features.
---
Now take Services, a fundamentally different approach that requires an API to actually be built from the ground up.
This inherently comes with more security and features, but with also with more dev work.
Shouldn't we consider actually creating a valid and stable API rather just "just exposing existing stuff"?
Its install base is over 10x larger than that of RestWS and with even more support of extension modules like:
https://www.drupal.org/project/services_api_key_auth
https://www.drupal.org/project/services_auth_apikeys
https://www.drupal.org/project/services_token_access
Granted, none of these have stable releases, but I can't even remotely find the same concept in even just one module/sandbox/gist/gh project for RestWS.
Comment #7
markhalliwellComment #8
MixologicPretty sure the reasoning was that RestWS is what was moving into d8 at the time, and in the eventual transition to d8 for drupal.org, we didnt want to have multiple api's to support. Maybe *services* should have gone into d8 and not restws, but that decision wasnt ours to make.
Comment #9
markhalliwellExcept that RestWS isn't really an API; it just exposes content in different formats.
The 8.x rest module was only "inspired" by RestWS, they're really not the same thing. Especially considering that in 8.x you can't use Accept headers (https://www.drupal.org/node/2501221) and instead requires a
_formatquery string parameter.Also, because it just "exposes existing content", this means that the fields and/or other properties are constructed using the current installation/configuration anyway.
A real API shouldn't be tied to the software implementing it. There should be a specific API defined property in a response. Not some arbitrary Drupal field definition (field_*) that has the potential of either getting removed/renamed when newer code/technologies come around.
So when d.o moves to 8.x, this "API" will no longer be the same and break existing apps/tools regardless.
Comment #10
drummThe RestWS API will go away with Drupal.org's upgrade past Drupal 7. While there is some possibility for time where reads from both the RestWS API and its replacement are supported, there is not a practical way for an easy transition of writes. Legacy API users would have writes turned off even more abruptly than for reads.
So I do not think this is worth the time to support, when it will only be temporary.