Cookie Notice

As far as I know, and as far as I remember, nothing in this page does anything with Cookies.

2015/09/03

So You Think You CAN REST

This is notes to self more than anything. Highly cribbed from http://www.restapitutorial.com/

First step toward making RESTful APIs is using the path info. If you have a program api.cgi, you can post to it, use get and api.cgi?foo=bar, or you can use path info and api.cgi/foo/bar instead.

You can still use parameters, but if you're dealing with a foo named bar, working with $api.cgi/foo/bar is shorter, because you're overloading it.

Generally, we're tossing things around as JSON, which, as object notation, is easier to convert to objects on either side of the client/server divide than XML.

You're overloading it by using request method. Generally using POST, GET, PUT and DELETE as the basic CRUD entities. You can browse to api.cgi/foo/bar and find out all about bar, but that's going to be a GET command. You can use curl or javascript or other things where you can force the request method to add and update.

This means that, in the part that handles 'foo', we handle the cases.

For read/GET, api.cgi/foo likely means you want a list of all foos, maybe with full info and maybe not, and api.cgi/foo/bar means you want all the information specific to the foo called bar.

For the rest of CRUD, api.cgi/foo is likely not defined, and should return an error as such.

So, in a sense, sub foo should be a bit like this:
  1. sub foo {  
  2.   
  3. my $id  = undef ;  
  4. if ( scalar @pathinfo ) { $id = $pathinfo[-1] }  
  5.   
  6. # READ  
  7. if ( $method eq 'GET' ) {  
  8.     if ( defined $id ) {  
  9.         my $info = get_info($id);  
  10.         status_200($infoif $info;  
  11.         status_204();  
  12.     }  
  13.     my $list = get_list();  
  14.     status_200($listif $list;  
  15.     status_204();  
  16. }  
  17.   
  18. # CREATE  
  19. if ( $method eq 'POST' ) {  
  20.     if$param ) {  
  21.         my $response = create($param);  
  22.         status_201() if $response;   
  23.         status_409() if $response == -409 ; # foo exists  
  24.         status_400() if $response < 0 ;  
  25.         status_204();  
  26.     }  
  27.     status_405();  
  28. }  
  29.   
  30. if ( $method eq 'PUT' ) {  
  31.     my $id  = undef ;  
  32.     if ( scalar @pathinfo ) { $id = $pathinfo[-1] }  
  33.     if ( $id && $param ) {  
  34.         my $response = update( $id$param ) ;  
  35.         status_201() if $response;   
  36.         status_400() if $response < 0 ;  
  37.         status_204();  
  38.         }  
  39.     status_405();  
  40. }  
  41.   
  42. if ( $method eq 'DELETE' ) {  
  43.     if ( defined $id ) {  
  44.         my $response = delete($id);  
  45.         status_400() if $response < 0 ;  
  46.         status_204(); # or 201  
  47.     }  
  48.     status_405();  
  49.     }  
  50. status_405();  
  51. }  

And those are standard HTTP status codes. Here's the Top Ten:
  • Success
    • 200 OK
    • 201 Created
    • 204 No Content
  • Redirection
    • 304 Not Modified
  • Client Error
    • 400 Bad Request
    • 401 Unauthorized
    • 403 Forbidden
    • 404 Not Found
    • 409 Conflict
  • Server Error
    • 500 Internal Server Error
Right now, I have the pathinfo stuff mostly handled in an elegant way. I see no good way of creating a big thing without using params, and the APIs generally use them too, I think.

My failing right now is that I'm not varying on request method and I'm basically sending 200s for everything, fail or not, and my first pass will likely be specific to individual modules, not pulled out to reusable code. Will have to work on that.

No comments:

Post a Comment