CODEBOXER.com

more on status codes

4 March 2010 | 10:54 am by codeboxer

Status Codes

Full detail: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

* 100 - Continue
* 101 - Switching Protocols
* 200 - OK
* 201 - Created
* 202 - Accepted
* 203 - Non-Authoritative Information
* 204 - No Content
* 205 - Reset Content
* 206 - Partial Content
* 300 - Multiple Choices
* 301 - Moved Permanently
* 302 - Found
* 303 - See Other
* 304 - Not Modified
* 305 - Use Proxy
* 306 - No Longer Used
* 307 - Temporary Redirect
* 400 - Bad Request
* 401 - Not Authorised
* 402 - Payment Required
* 403 - Forbidden
* 404 - Not Found
* 405 - Method Not Allowed
* 406 - Not Acceptable
* 407 - Proxy Authentication Required
* 408 - Request Timeout
* 409 - Conflict
* 410 - Gone
* 411 - Length Required
* 412 - Precondition Failed
* 413 - Request Entity Too Large
* 414 - Request URI Too Long
* 415 - Unsupported Media Type
* 416 - Requested Range Not Satisfiable
* 417 - Expectation Failed
* 500 - Internal Server Error
* 501 - Not Implemented
* 502 - Bad Gateway
* 503 - Service Unavailable
* 504 - Gateway Timeout
* 505 - HTTP Version Not Supported

status codes 101

18 June 2009 | 6:47 pm by codeboxer

Ah, the old http status code. Very nice. I recently built my first pro-grade web service and had some problems figuring out the status codes. Here are some tips from my friend happyfrenchy2:

Usually I write my rest service so that a problem with the parameters (wrong ID, not enough params, etc) returns a 400 (bad request), a auth failure (wrong signature) returns a 403 (forbidden) and an internal problem (couldn’t access DB for instance) returns a 503 (server error). Return code 500 should be when the error happens before your code was even reached (like the server or web-server is down).

Very helpful. This is what that looks like, in the create method of the /installs web service:

  def create

    respond_to do |format|
      format.xml {
        install = OnInstall.new do |i|
          i.ip_address = request.remote_ip
          i.mac_address = params[:mac_address]
          i.on_dvd_id = params[:on_dvd_id].to_i
          i.on_dvd_number = params[:on_dvd_number]
          i.on_dvd_set_id = params[:on_dvd_set_id].to_i
          i.on_game_id = params[:on_game_id].to_i
        end
        ts_param = params[:redacted]
        hash_to_match = params[:redacted]
        begin
          #FK validations
          test = OnDvd.find(install.on_dvd_id)
          test = OnDvdSet.find(install.on_dvd_set_id)
          test = OnGame.find(install.on_game_id)
          
          #validate md5 hash
          live_matcher = "redacted"
          digest = Digest::MD5.hexdigest(live_matcher)
          if digest.upcase == hash_to_match.upcase
            if install.save
              headers['location'] = on_install_path(install.id)
              render :nothing => true, :status => "201 Created"
            else
              render :xml => install.errors.to_xml, :status => "400 Bad Request"
            end
          else
            render :xml => "Your s param hash did not match the POST fields.", :status => "403 Forbidden"
          end
          
        rescue Exception => e 
          render :xml => e.message, :status => "503 Server Error"
        end
        }
      format.html {if current_user == :false then redirect_to home_url else super end}
    end
  end

asynchronous javascript FTW

18 November 2008 | 2:54 am by codeboxer

link_to_remote(name, options = {}, html_options = {})

Returns a link to a remote action defined by options[:url] (using the url_for format) that's called in the background using XMLHttpRequest. The result of that request can then be inserted into a DOM object whose id can be specified with options[:update]. Usually, the result would be a partial prepared by the controller with either render_partial or render_partial_collection.

Examples:

link_to_remote "Delete this post", :update => "posts", :url => { :action => "destroy", :id => post.id }
link_to_remote(image_tag("refresh"), :update => "emails", :url => { :action => "list_emails" })
You can also specify a hash for options[:update] to allow for easy redirection of output to an other DOM element if a server-side error occurs:

Example:

link_to_remote "Delete this post",
:url => { :action => "destroy", :id => post.id },
:update => { :success => "posts", :failure => "error" }

Optionally, you can use the options[: position] parameter to influence how the target DOM element is updated. It must be one of :before, :top, :bottom, or :after.

By default, these remote requests are processed asynchronously during which various JavaScript callbacks can be triggered (for progress indicators and the likes). All callbacks get access to the request object, which holds the underlying XMLHttpRequest.

To access the server response, use request.responseText, to find out the HTTP status, use request.status.

Example:
link_to_remote word,
:url => { :action => "undo", :n => word_counter },
:complete => "undoRequestCompleted(request)"

The callbacks that may be specified are (in order):
:loading: Called when the remote document is being loaded with data by the browser.
:loaded: Called when the browser has finished loading the remote document.
:interactive: Called when the user can interact with the remote document, even though it has not finished loading.
:success: Called when the XMLHttpRequest is completed, and the HTTP status code is in the 2XX range.
:failure: Called when the XMLHttpRequest is completed, and the HTTP status code is not in the 2XX range.
:complete: Called when the XMLHttpRequest is complete (fires after success/failure if they are present).

You can further refine :success and :failure by adding additional callbacks for specific status codes:

Example:

link_to_remote word,
:url => { :action => "action" },
404 => "alert('Not found...? Wrong URL...?')",
:failure => "alert('HTTP Error ' + request.status + '!')"

A status code callback overrides the success/failure handlers if present.