Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>No, it is not RESTful. The only reason why you should be putting a verb (<code>force_delete</code>) into the URI is if you would need to overload GET/POST methods in an environment where PUT/DELETE methods are not available. Judging from your use of the DELETE method, this is not the case.</p> <p>HTTP error code <code>409/Conflict</code> should be used for situations where there is a conflict which prevents the RESTful service to perform the operation, but there is still a chance that the user might be able to resolve the conflict himself. A pre-deletion confirmation (where there are no real conflicts which would prevent deletion) is not a conflict per se, as nothing prevents the API from performing the requested operation.</p> <p>As Alex said (I don't know who downvoted him, he is correct), this should be handled in the UI, because a RESTful service as such just processes requests and should be therefore stateless (i.e. it must not rely on confirmations by holding any server-side information about of a request).</p> <p>Two examples how to do this in UI would be to:</p> <ul> <li><em>pre-HTML5</em>:* show a JS confirmation dialog to the user, and send the request only if the user confirms it</li> <li><em>HTML5</em>:* use a form with action DELETE where the form would contain only "Confirm" and "Cancel" buttons ("Confirm" would be the submit button)</li> </ul> <p>(*) Please note that HTML versions prior to 5 do not support PUT and DELETE HTTP methods natively, however most modern browsers can do these two methods via AJAX calls. See <a href="https://stackoverflow.com/questions/165779/are-the-put-delete-head-etc-methods-available-in-most-web-browsers">this thread</a> for details about cross-browser support.</p> <hr> <p><strong><em>Update</em></strong> <em>(based on additional investigation and discussions):</em><br /></p> <p>The scenario where the service would require the <code>force_delete=true</code> flag to be present violates the <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5" rel="nofollow noreferrer">uniform interface</a> as defined in Roy Fielding's dissertation. Also, as per <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7" rel="nofollow noreferrer">HTTP RFC</a>, the DELETE method may be overridden on the origin server (client), implying that this is not done on the target server (service).</p> <p>So once the service receives a DELETE request, it should process it without needing any additional confirmation (regardless if the service actually performs the operation).</p>
    singulars
    1. This table or related slice is empty.
    1. POREST, HTTP DELETE and parameters
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USMicE
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POREST, HTTP DELETE and parameters
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COCould you explain which REST constraint is being violated? Considering that URIs should be opaque to the client, why do you believe that the client's expectations are not being met with the usage of an HTTP DELETE that deletes one resource but fails to delete another. I'm not sure 409 is the best status code to return but besides being a bit of a strange implementation, I cannot find any REST constraints that are being broken.
      singulars
      1. PO
      1. USDarrel Miller
    2. CO+1 for the well-argued opinion. I think you are arguing that in the absence of PUT/DELETE one should use POST to change the state of the resource but DELETE is available. I agree with that however DELETE is available and I haven'ts seen anything to suggest that using the URI like this is actually wrong - it still identifies the underlying resource.
      singulars
      1. PO
      1. USChris McCauley
    3. COThere is a conflict in my scenario - the resource state suggests that it is in use and should not be deleted.
      singulars
      1. PO
      1. USChris McCauley
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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