0

So, I'm building a Web site application that will comprise a small set of content files each dedicated to a general purpose, rather than a large set of files each dedicated to a particular piece of information. In other words, instead of /index.php, /aboutme.php, /contact.php, etc., there would just be /index.php (basically just a shell with HTML and ) and then content.php, error.php, 404.php, etc.

To deliver content, I plan to store "directory structures" and associated content in a data table, capture URIs, and then query the data table to see if the URI matches a stored "directory structure". If there's a match, the associated content will be returned to the application, which will use Pear's HTTP_Request2 to send a request to content.php. Then, content.php will display the appropriate content that was returned from the database.

EDIT 1: For example:

  • a user types www.somesite.com/contact/ into their browser
  • index.php loads
  • a script upstream of the HTML header on index.php does the following:
    • submits a mysql query and looks for WHERE path = $_SERVER[REQUEST_URI]
    • if it finds a match, it sets $content = $dbResults->content and POSTs $content to /pages/content.php for display. The original URI is preserved, although /pages/content.php and /index.php are actually delivering the content
    • if it finds no match, the contents of /pages/404.php are returned to the user. Here, too, the original URI is preserved even though index.php and /pages/404.php are actually delivering the content.

Is this a RESTful approach? On the one hand, the URI is being used to access a particular resource (a tuple in a data table), but on the other hand, I guess I always thought of a "resource" as an actual file in an actual directory.

I'm not looking to be a REST purist, I'm just really delving into the more esoteric aspects of and approaches to working with HTTP and am looking to refine my knowledge and understanding...

Eric Fuller
  • 159
  • 1
  • 8
  • Just read the http spec if you want knowledge and understanding of rest – CBIII Jul 26 '13 at 03:01
  • Wouldn't I need to read the [doctoral dissertation](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) on the subject? I understand that it's basically an "ascetic" approach to HTTP (so, understanding HTTP will get you pretty far), but what constitutes a valid "resource" that may be identified by a URI in the REST philosophy? Does the HTTP spec address that kind of thing? I realize the dissertation and the spec might illuminate these things, but I'm burning the candle at both ends these days as it is...so I thought I'd try conversation ;). – Eric Fuller Jul 26 '13 at 03:12
  • 5.2.1.1 of the dissertation kind of implies that just about anything you can name can be a resource, be it a file, a tuple, a cat, or whatever. But, it seems to say when one edits the contents of /some/content/, /some/content/ would need to point to the original version indefinitely and some new URI would need to point to the edited version. If that's the case, I don't see myself becoming a purist any time soon ;). – Eric Fuller Jul 26 '13 at 03:26
  • Please edit your question to include some the URIs you plan to use and the the response of each would be. A Resource in REST does not correspond to a file, it can be anything with an URI on which to use HTTP verbs makes sense. –  Jul 26 '13 at 04:50
  • Tichodroma, thanks. Please see Edit 1 in the original post and please let me know if I can clarify further. The last part of your comment is pretty illuminating. The only direct use I make of the URI involves a SQL "verb" (SELECT), not an HTTP "verb". In this context, the POST method will only be sent to one of a very small set of resources (files), regardless of the URI. So, the URI is used to determine if there are relevant contents to package in a POST method, but doesn't determine where the POST method is sent (the script does that). Is that RESTful, not RESTful, or somewhere in between? – Eric Fuller Jul 26 '13 at 16:14
  • I just stumbled upon [this page](http://blog.rjzaworski.com/2011/11/developing-with-rest/), which rather directly addresses these issues. It seems to suggest that my architecture is indeed RESTful (at least in spirit, if not in execution so far), but I have to read more before posting it as part of a suggested answer. – Eric Fuller Jul 26 '13 at 16:22
  • Sorry, found another one, this time [on SO](http://stackoverflow.com/questions/1164154/is-that-rest-api-really-rpc-roy-fielding-seems-to-think-so?rq=1). That seems to suggest that I'm on the right track, but this throws me off: "A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). ..." Does storing URI hierarchies in a database (or JSON or XML, etc.) run afoul of this, or is it only a problem if the these hierarchies are available in the app layer? I'd ask this on that thread, but I don't have the rep yet ;) – Eric Fuller Jul 26 '13 at 16:38
  • Ugh, sorry, I think things are finally starting to click. Am I correct in thinking that the following are equivalent, conceptually? __REST API:__ www.somesite.com/getresource/arg1 __Java API:__ someobject.getResource(arg1); Then, what you do with those calls is almost beside the point? – Eric Fuller Jul 26 '13 at 16:49

1 Answers1

0

OK, my conclusion is that there is nothing inherently unRESTful about my approach, but how I use the URIs to access the data tables seems to be critical. I don't think it's in the spirit of REST to store a resource's full path in that resource's row in a data table.

Instead, I think it's important to have a unique tuple for each "directory" referenced in a URI. The way I'm setting this up now is to create a "collection" table and a "resource" table. A collection is a group of resources, and a resource is a single entity (a content page, an image, etc., or even a collection, which allows for nesting and taxonomic structuring).

So, for instance, /portfolio would correspond with a portfolio entry in the collection table and the resource table, as would /portfolio/spec-ads; however, /portfolio/spec-ads/hersheys-spec-ad would correspond to an entry only in the resource table. That entry would contain, say, embed code for a Hershey's spec ad on YouTube.

I'm still working out an efficient way to build a query from a parsed URI with multiple "directories," but I'm getting there. The next step will be to work the other way and build a query that constructs a nav system with RESTful URIs. Again, though, I think the approach I laid out in the original question is RESTful, so long as I properly correlate URIs, queries, and the data architecture.

The more I walk down this path, the more I like it...

Eric Fuller
  • 159
  • 1
  • 8