restful-drupal/restful

RESTful best practices for Drupal

restful's Issues

Add a better delivery callback.

Using drupal_json_output as our delivery callback overwrites the Content-Type header hardcoding it to application/json. We want it to respect our custom Content-Type headers as long as it's of type json (application/hal+json, application/problem+json, …).

Solve in a more generic way setting "format" for text fields on POST

https://github.com/Gizra/restful/pull/74/files#r14169608

Add missing documentation for IETF API-Problem

This is a follow up for #49

Add an HMAC authentication API provider

This might be in the realm of a contributed add-on, but it would be great to implement an HMAC authentication provider to give a more secure option than HTTP basic authentication or session-based authentication. Acquia recently released an open-source library to facilitate implement such a system at https://github.com/acquia/hmac-request.

Thanks in advance for your consideration,
Chris

Use PATCH instead of PUT

PUT was a mistake I meant PATCH ;)

Add pagination support to getList()

This will possibly also be the first time to introduce Hateoas - where we'll add links for the previous/ next links

Hijack api/* to be under RESTful

Imagine a client calling a non existing resource (e.g. api/v1/article -- instead of articles).

Currently the result is HTML with a 404.
I would expect RESTful to take control and return a proper JSON response.

Refactor RestfulEntityBase into RestfulBase

Move everything that is not entity related to RestfulBase.

Remove advanced help?

@mateu-aguilo-bosch I'm thinking out loud. Should we keep the advanced help -- currently the docs are a todo, which is fine, I just wonder if they'll ever be something that would be valuable for users.

Maybe if it was easy to assign a customisable link so they would direct to help.example.com?

Add basic auth provider.

Avoid error message on empty property.

field_uuid information taken from getPublicFields() does not include property.
It includes only callback.

      // Skip fields that doesn't have property configures, such as UUID field.
      if (!isset($info['property'])) {
        continue;
      }

      $property_name = $info['property'];

When access is denied restful_json_output() gets wrong output

If the access callback of the menu item returns FALSE, then the output would be 3 (which is actually MENU_ACCESS_DENIED) with status code 200.

We should call drupal_deliver_html_page() in case of int values.

Validate the entity with the entity validate module

We already using the Entity validate module in OpenScholar. I think this can be good addition. Dependent PR: Gizra/entity_validator#8

Allow register to site

I'd like to play with the idea of a completely decoupled register.

Error due to "rate_limit" entity type does not exist on 8.x-1.x

1. Installing last D8 alpha.
2. Cloning restful and enabling restful and restful example modules.
   Gives a fatal error:
   
   And in the log we get:
   [Thu Sep 04 09:33:28 2014] [error] [client 127.0.0.1] Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "rate_limit" entity type does not exist." at /var/www/d8/www/core/lib/Drupal/Core/Entity/EntityManager.php line 207

Pass $wrapper to RestfulEntityBase::entityPreSave()

Instead of the entity itself. Like we do for RestfulEntityBase::entityValidate()

Move header logic to formatter.

In order to keep thinks self-contained move the response header stuff into the formatter (maybe RestfulBase?).

This depends on: #132

Request of a single asset should not yield pagination and count results.

• Make sure that no count or pagination links are returned.
• Add test coverage.

Related to #129.

Provide image style integration for image fields.

The idea is to have some extra configuration for the image fields (maybe also think of a generic way to have extra config for fields with nice helper methods) that will list an array of image styles.

That way we can output different image urls for different sizes. I think this is important b/c client apps usually are not great at resizing images and also there's bandwidth to consider.

So when we build the return array for an entity that contains an image field we output the url to the original image and all image styles listed for that field instance for that particular endpoint.

CSRF security vulnerabilty on write operations with session cookies

Since this module does not have a stable release on drupal.org yet I think it is fine to report security issues in public (see our policy https://www.drupal.org/security-advisory-policy ).

I have not looked to closely at the code and have not tried to exploit this yet, but I think there could be a CSRF vulnerability on write operations such as POST, PUT and DELETE requests when using session cookie authentication.

This happened in the past to other Drupal REST server solutions:
RESTWS: https://www.drupal.org/node/1890222 and http://cgit.drupalcode.org/restws/commit/?id=dae7e2e
Services: https://www.drupal.org/node/2012982
Drupal 8 core: https://www.drupal.org/node/1891052

Maybe I overlooked something, do you already handle this case somehow?

Allow empty values in patch and put requests.

When using the patch() or put() methods to update an entity there's no way to empty a field's value in case of a field with cardinality of 1. In the function setProperyValues() we check:
if (!isset($request[$public_property]))
And if we send a value of NULL we skip this property and we get an exception later on.

Note that for fields that are multiple this works fine by sending array(NULL) in the request for that property.

Copy file_save_upload() to get better error details

https://github.com/Gizra/restful/blob/7b8502ae74f9ab841bcf17ce8ffeed4873c1315b/plugins/restful/file/files_upload/1.0/RestfulFilesUpload.class.php#L51

file_save_upload() isn't API friendly. The errors are sent via drupal_set_message().
We could copy file_save_upload() and run the validations ourself, so when we hit a validation error we'll have better error messages.

Token auth provider

• I think we should add a submodule called restful_token_auth that will provide an endpoint to login/ register/ retrieve password via CURL.
• Response will return a token string.
• We can have a fieldable token_auth entity that will have the token info, along with the user it's related to, and the created/ expire info.

Once we have this we can create an example repo of a completely decoupled AngularJs webapp talking with a completely RESTful Drupal. Which is pretty awesome ;)

Use namespaces to simplify class names.

Class names are getting crazy lately. Maybe we should start thinking about adding a root namespace \Restful and then use it everywhere. Deeper nesting can also provide some clarity.

Maybe we'll need to depend on xhautoload, but I think that would be an overkill at this point.

@amitaibu thoughts?

Add base taxonomy class

Resources from entity type "taxonomy" need a separate taxonomy base class because the base class of "Node" have a property condition of status to expose only published nodes which taxonomy doesn't have.

Consider using the IETF API-Problem specification for error messages

Cool module.

One recommendation is to consider adopting the IETF API-Problem specification for error messages. There is a good blog post at https://www.mnot.net/blog/2013/05/15/http_problem that gives an overview of why this is useful, and there is some tooling in PHP at https://github.com/Crell/ApiProblem to help facilitate rendering spec-compliant messages.

Thanks!
Chris

Questions around OAuth2 integration

I'm looking into integrating oauth2_server and Restful.

Problem #1
Restful's fancy error handling.
oauth2_server_verify_access() likes to do that by itself (output 401 + the json body with additional info), that comes from the underlying library mostly.
Now, there are only a few possible errors, so I could translate that into what a restful user would expect, but it wouldn't be consistent with the errors that the oauth2 endpoints (oauth2/authorize, oauth2/token) are throwing
(those are completely outside restful so they can't be affected + the list is huge)
So the question is whether to be inconsistent, or inconsiderate (by throwing our own errors and doing a drupal_exit() inside the authorization plugin)

Problem #2
Scopes. I need to have a way to specify a needed scope per action ("get" requires "view" but "post" requires "administration view" for example). I can add some settings to the plugin metadata, but it feels like there should be a way to describe the actions (what's in $controllers + authorization info, for starters)

Inject file validators and scheme from the plugin

#79 (comment)

Use rate-limit for flood control on base_auth authentication provider.

See here

Inject classes from plugin definition

https://github.com/Gizra/restful/pull/53/files#r13242933

Add PHPdoct to restful_plugin_process()

"count" property doesn't take filters into account

For example:

Add test for the file upload

Follow up for #79

Genreal rate limit

Currently our rate limit is per resource.
It would be nicer to be able to say, like Github has, you may access any resource up to 5000 in total.

Prepare for release

@mateu-aguilo-bosch

I'd like to suggest an approach for getting release/ RC/ Beta or whatever we decide to call it out:

I've added a "release blocker" label, so both you and I can mark freely the issues we want to tackle.
Let's time-box the effort by setting a soft limit to the end of Sep (i.e. the beginning of DrupalCon Amsterdam).

Que pensas?

Allow uploading files

Port to D8

This should be done probably only after we've reached an alpha -- which I feel we're pretty close.

I'm just putting a name here. not implying anything. @fubhy :)

Allow "X-HTTP-Method-Override"

For clients that don't have PATCH/ PUT

Clean restful installation on clean D7 creates an irrelevant menu item

See

Allow filtering getList()

$request = array(
  'sort' => 'id',
  'filter' => array('value' => '1,2', 'operator' => 'IN'),
);

Add more (and better) authentication tests

Add a bit of docs about rate limit

cause they are needed :)

Self Documenting REST API

Would be nice to have something as @larowlan did for D8's REST https://www.drupal.org/project/rest_api_doc

Allow creating sub-resources in a single request

For example, if we have a node that reference a new term, currently you need 2 requests: one to create the term, and the other to create the node that references it.

Since RESTful already has an option to map a resource to an entity-reference field, we could save that extra request.

This one is a little hard, as if one entity isn't valid, it should fail the others, so we might opt for a db_transaction() here.

@mateu-aguilo-bosch thoughts?

Improve the logic of imageProcess and image_styles

@mateu-aguilo-bosch
Currently the new image_styles will work only if one would implement something similar to \RestfulExampleArticlesResource__1_5::imageProcess().

Maybe we should move imageProcess() to the base class as-well?

Integrate with "Entity validator"

Entity validator is a new (and still under lots of development) module we work on in Gizra, that I can think compliment RESTful, when it comes to validating a created/ updated entity.

cc @mateu-aguilo-bosch

Return 401 for missing user instead of 403.

Create output plugin for output format flexibility.

I think RESTful should be opinionated about the output format. A variation of JSON API is my preferred format and I'd like to see the module following that. The only I'd like to have with it is that I think that when getting a specific single item we should not be returning an array with only one item but an object. I also like having "data" as a common object key for … well, data.

Having an output plugin and defining our default one (json_api_custom) will allow module integrators to easily have APIs in YML, other JSON structures, or $deity forbids… XML.

Pulse the community opinions on decoupling Drupal.

Maybe this is worth some reading/talks.

https://groups.drupal.org/headless-drupal

Get posted data for PUT and PATCH.