Merge with Plack::Middleware::RestAPI

[nichtich]

I wonder what Plack::Middleware::RestAPI can do above Plack::Middleware::REST. We should merge both modules to not confuse possible users which module to use. In my personal opinion it is not good to modify the PSGI $env but we could add a possibility to configure Plack::Middleware::REST with an object:

...
enable 'REST',
    resource => My::API::Resource->new,
    collection => My::API::Collection->new,
...

package My::API::Resource;
sub GET { ... }   # get
sub HEAD { ... } # get
sub POST { ... } # 

package My::API::Collection;
sub DELETE { ... } # delete resource
sub POST { ... }     # create resource
sub GET { ... }       # list resources

However, I'd prefer not naming the methods with HTTP methods so one use the same object as resource and collection:

package My::API;
sub get { ... }   # GET and HEAD on resources
sub upsert { ... } # PUT on a resource
sub patch { ... } # PATCH on resource
sub delete { ... } # DELETE on resource
sub list { ... }   # GET on collection
sub create { ... } # POST on collection

...
enable 'REST', via => My::API->new;

In the end the latter could also be done the other way round:

package My::API;
use parent 'Plack::Middleware::REST'; # or Plakc::App::REST
# just defined method get, upsert, delete... to support these methods

[vasekd]

It is possible, but we should invent some way how to set a lot of resources.
With Plack::Middleware::RestAPI you can set for example 30 resources just only with URLMap's mount:

builder {
  enable 'RestAPI';

  mount "/" => sub { 'Test::Root' };
  mount "/test" => sub { 'Test::Test' };
  mount "/test1" => sub { 'Test::Test1' };
  mount "/test2" => sub { 'Test::Test2' };
  ....
};

In Plack::Middleware::REST it is very complicated. Because you have to set each method for each recource.

I have no problem to implement this behaviour to Plack::Middleware::REST.
But I think that it is a little different approach.

[nichtich]

With 30 resources I'd always store the mapping in a hash and build the app such as:

builder {
  enable 'RestAPI';
  while (my ($path, $class) = each %routes) {
    mount $path => sub { $class };
  }
}

Nevertheless we could make Plack::Middleware::REST support such syntax:

builder {
  mount "/" => Plack::Middleware::REST->new( via => 'Test::Root' );
  mount "/test" => Plack::Middleware::REST->new( via => 'Test::Test' );
  mount "/test1" => Plack::Middleware::REST->new( via => 'Test::Test1' );
  mount "/test2" => Plack::Middleware::REST->new( via => 'Test::Test2' );
  ....
};

Would this suite your use case?

[vasekd]

Ok, I know while loop, but it was the example.

Second one is a good idea. But in this case, the name of library should be Plack::App::REST, because it returns app. Similar as for example Plack::App::File.

[towhans]

That would be great. Let's call it Plack::App::Methods

[nichtich]

I'd prefer Plack::App::REST because "Methods" is ambiguous. The module can be part of this package.

[towhans]

That's OK with me.

[vasekd]

Ok, I have created Plack::App::REST. See: github
And I will set Plack::Middleware::RestApi as deprecated.
Thank you for your comments and ideas

[nichtich]

@vasekd thanks, I'll look into further merging with Plack::Middleware::REST, so both will be fully compatible.