Should we support common restful conventions?

[Adam Schnaare]

As I thought through the usage of this backend architecture, one thing became clear to me: the restful functions setup won't support restful conventions easily. Specifically, the structure of resources as REST defines them.

• At present we have something like users/restful/addUser.endpoint.ts which results in a url like .../users-api/addUser.
• Restful convention would frown on adding the verb to the user resource. It would prefer something like a POST request to an endpoint like ...users-api/users

RESTful conventional patterns to consider:

• GET /users
• POST /users
• GET /users/{uid}
• DELETE /users/{uid}
• GET /users/{uid}/somethingElse

Our options as I see it

1. As is supports a more flat, customizable solution, but deviates from what external users of any api would expect. (we would probably have to handle all uids, etc via the request body.
2. Supporting common RESTful convention would introduce a layer of complexity, but could be done.

[Dane Mackier]

@adamschnaare I was thinking about this too, and the reason that I didn't add any support for this is because

1. CRUD operations will be done directly on firestore using the firestore packages.
2. The RESTful functions are for "combining backend behaviours" into a single endpoint. Something like a checkout request, where you don't want the client using it to manually do all CRUD involved in a checkout process.

This is also the reason that the original definition of the functions were "idle" functions. A function that will sit idle until a client makes a request to it. But it was a new word to introduce and we were better off using Restful as the function type even though it's not the same.

Because of the fact that we'll never write crud operations through the restful endpoint, unless it's a batch operation, I don't think doing work on this feature would benefit the backend project. But just to be clear again, I have thought of this too but kept coming to the same conclusion.

This is the only case that I'm hoping the users of this package will always want to use firestore in their clients as well.

[Adam Schnaare]

Roger that. I can settle around that idea.