What am I not understanding about REST?

Question

I\'m building a framework and want developers who build with it to have the ability to allow parts of it to both share data with other sites and allow other sites to add/edi

Answer 1

I suggest you read this post by Roy Fielding.

A highlight:

• A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

• A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling].

You certainly can be successful using a RPC-like approach as you describe and it's easier to grasp than a 'proper REST API'. The most misunderstood aspect of REST is that, once defined, it should automatically work, you should not define go to this URI using this method to get that answer, that should all be implied by the media types you are delivering plus a means to let clients know where to find the relevant resources.