Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Makes sense to me. Although I don't get why using the different HTTP methods is better then just using just the normal GET/POST and using a URL structure like:</p> <pre><code>movies/10/edit movies/10/ratings/add movies/10/ratings/10/reply movies/10/ratings/10/edit movies/10/tags movies/10/tags/add movies/10/tags/10/remove </code></pre> <p>... and so on. The latter makes much more sense to me and would be more clear IMO to the person consuming your web service. Also, the amount of operations you can perform on a "node" is undefined whereas using your current method you can only perform a set amount of methods (GET, PUT, POST, DELETE)</p> <p>:)</p> <p>If I am missing something (have not dealt with REST before) then please let me know why it is better to use the HTTP methods (thus limiting your operations and not feeling "right" with defining a difference between PUT and POST) over the conventional method.</p> <p><strong>In response to comments</strong></p> <p>Wait, so... HTTP defines four verbs; but also defines the ability for us to name our URIs whatever we want. So instead of appending the verb to the end of the URI:</p> <pre><code>movies/10/edit </code></pre> <p>We are just conforming to the verbs defined by the underlying protocol. That sounds foolish to me. I would need some hardcore convincing that this is a better way to do things in order to change my mind. It sounds a bit "fad"ish to me; like when AJAX came out and everybody jumped on using XML to represent data (thus slowing systems down because of the time it takes to parse and coerce) and consuming much more bandwidth then needed) and now we are stuck with SOAP.</p> <p>How is limiting your verb vocab better?</p> <p>I don't mean to sound hostile at all; but like I said, I don't like fads and this looks like one to me unless somebody can give me a reason not to think that way.</p> <p><strong>In response to comments #2</strong></p> <p>I have no problem with XML at all. As a Markup Language. As in eXtensible <strong>Markup Language</strong>. If you look at <a href="http://en.wikipedia.org/wiki/Markup_language" rel="nofollow noreferrer">Wikipedia</a> you will see that using XML as a data structure goes beyond its intended use. Don't get me wrong - if all things IT was always used in the ways that it was intended when it was built we would never evolve. But using XML over a binary format to transfer data from program to program is inane.</p> <ul> <li>XML documents balloon the size of the actual data with a human-readable syntax when, in most cases XML is used, humans never actually read or edit the content themselves.</li> <li>XML takes time and memory to load, parse and coerce the values inside attributes and nodes into a format that a computer can understand.</li> </ul> <p>Using something like JSON (although that is not a binary format either - but it is a format which can be nativity executed on a JS VM) is much better for performance and memory allocation in AJAX - and as far as SOAP goes it simply blows my mind that a "computer-to-computer" protocol would be written in a language that was specifically designed to be human-editable.</p> <p>Take Magento for example (the ecommerce platform). It uses one or more XML config file per module. But in order to make their already-very-slow application (I love Magento BTW, but it is MUCH MUCH slower then it needs to be) faster, they write code that serializes the array that was built using the XML config files so it can load faster. If they just did something like:</p> <pre><code>&lt;?php $this-&gt;SetConfig(array( "Database" =&gt; array( "host" =&gt; "localhost"))); ?&gt; </code></pre> <p>(this config file would be "required" from within the method of the config class that is instanced per module)</p> <p>Instead of that XML crap the application would most certainly speed up; and would reduce the amount of "optimization code" they had to write.</p> <p>Yes, XML is a fad. Yes, XML is over-used in situations it should never be used in. XML certainly has its place (XHTML, template engines) but NOT for storing config files, data files, or computer-to-computer interactions.</p> <p>As far as REST goes, I misunderstood what it was. It does look interesting though; I'll look into it more though. But because of fads like XML I am hesitant to jump on these emerging practices.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload