Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Create resource schema that represents a Resource #115

Closed
Marak opened this Issue · 7 comments

3 participants

@Marak

Currently, there is no easy way to enumerate all the possible configuration options of a Resource. We should have a schema that defines what a resource can be.

I recommend building the Resource resource using the resourceful API ( versus pure JSON-Schema ). You can always pull the JSON-Schema back out of resourceful using the Resource.schema field.

The schema for a resource would define the following structure:

  • Name of the resource
  • Expected CRUD methods
  • Unexpected arbitrary remote methods
  • Relationships to other resources
  • Engine Configuration ( database connection details )
  • types of properties allowed
    • the configuration options allowed for property types

The last point is particularly important. For instance, String type has a format option that may be email. Number has maximum and minimum options which expect numerical values. Currently, there is no programatic way to look this information up.

Once we are able to easily reference this information as a schema / resource, resourceful can become "self-hosted" in the sense that we can use resourceful reflection tools ( restful / formful / socketful / commandful ) to create new Resource definitions dynamically.

@Marak

Got a partial start here: https://gist.github.com/bf21229c7a1d6ae02884

Using the types / options schema data in that gist for another project, will update as I go.

@raix

Remember auth... It should be part of a ressource definition to define roles for the different actions (cruds)?
A self defining ressource would be nice, would be Nice if the definition could be used ón the client for making a client js api interface. Maybe even localstorage api with sync...

@Marak

@raix In regards to your comment about the client:

I'm currently working on making the RESTful ( request module ) and socketful ( socket.io ) engines isomorphic.

see:

This means seamless client or server communication to an existing https://github.com/flatiron/restful or https://github.com/flatiron/socketful server. i.e, define a resource, get a client and a server

Any help on either of these branches would be appreciated. They are both already mostly working ( with tests ).

@Marak

@raix - Also, for now, there is director-reflector, which will create JS client API for any Director.router instance, which is what restful uses to generate routing maps.

Cheers!

@raix
@fkhbgm

Also interested by this and willing to help instead of writing my own logic.
as @raix noticed, the direction is important.
Here is mine:
Shared between browser and nodejs

  • description of resources and relations
  • validation code (even custom code)
  • REST service description Server side only:
  • storage (db) description After reading your comments, I think an abstraction may be possible between REST/Socket/localstorage/dbstorage... even if I think that in serious cases, implementation of each layer (or how the entity is mapped/consumed) will be different. For such a service to be usefull, the most important things are: easy and declarative way for 'standard' cases. full possibilities of extensions for the others. This can be a backbone for many other value-added modules...
@Marak

invalid

@Marak Marak closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.