refactor delete with links in rest.js

[bourgeoa]

@jeff-zucker
I refactored the delete with links functions in rest.js. Passes all tests (added 2)
This is solid spec and not file system related.

• _deleteContainer() and _deleteResource() in rest.js
• create a _getLinks() and isLink() in rest.js (may be it should be _isLink())
• Renamed in each storage handler :
  deleteResource -> deleteFile
deleteContainer -> deleteDir
  Hope this do not raise issues on actual storageHandler usage. (not used in your browser test)

added POST forbidden (403) for links. Need to use PUT see issue #28

[Otto-AA]

Renamed in each storage handler :
deleteResource -> deleteFile
deleteContainer -> deleteDir

In theory, this would require a major release (v2.0.0) as it breaks custom storage handlers defined outside of this package (plugins). [EDIT: npm docs on semver: https://docs.npmjs.com/about-semantic-versioning#incrementing-semantic-versions-in-published-packages ]

To be clear, here's a simple example project that would be broken:

// index.js
const SolidRest = require('solid-rest')
const CachedStorage = require('./cachedStorage.js')

const rest = new SolidRest(new CachedStorage())
rest.fetch('foo')

// cachedStorage.js
class CachedStorage {
  async deleteContainer(pathname){
    // delete container
  }
  // other methods...
}

When using the new solid-rest this project would get broken, because it has no deleteDir method defined. Hence versioning would need to reflect this as a breaking change.

[Otto-AA]

In practice I don't know if anyone made a custom storage, I don't think we can know if anyone would be affected. But in this case you could just leave the old naming until the next major release.

[jeff-zucker]

@bourgeoa > Renamed in each storage handler : deleteResource -> deleteFile deleteContainer -> deleteDir

Why?

[bourgeoa]

Thanks.
I suppose seeing your reactions that it has been a bad idea.
I just felt that file/folder/dir words are related to fileSystem and Resource/Container to Solid, and it would be clearer
I forgot that it is not a new project.

I commented Hope this do not raise issues on actual storageHandler usage. (not used in your browser test)
In fact I was thinking that might be a problem. That the reason I commented.
No problem to revert.

Can you give me other comments.
I'm still on the learning curve on open source projects.

Is it a good idea to create a restUtils.js or a utils folder with some functions like _getParent() isLink() getExtension() ....

[jeff-zucker]

I understand the thought of making the commands more file-system based but consider that solid-rest may eventually be used on things like databases rather than file systems in which neither the terms "folder" and "contrainer" apply. I think your suggestion about utils and some of @Otto-AA 's suggestions are good but I have to say I am somewhat frantic about being able to keep up with my modules and really need to concentrate on keeping them working rather than enhancements. Are y'all able to mark things as enhancements? Or just say so with regards to suggestions so I can keep track. There are going to be huge changes to solid-auth-cli coming and or a completely different way of integrating solid-rest, so I need to keep my eye on that ball.

[jeff-zucker]

I am going to merge this, then go in and change the deleteFile and deleteDir back to original.