Skip to content
Commits on Feb 12, 2014
Commits on Sep 15, 2013
  1. Move to subdir for Racket package.

    committed
    To be compatible with Racket <= 5.3.6. I forgot that the single
    collection option is still not officially released.
  2. Add .gitignore

    committed
Commits on Sep 14, 2013
  1. Racket package.

    committed
  2. Support repeating parameters.

    committed
    Some web APIs need this. For example a `foo` query parameter may be
    supplied multiple times, with different values.
    
    Since we're using a `dict`, we represent this as still just one dict
    entry, but if the value is list? then we spread it out into multiple
    query parameters. Note this is also supported for headers, which is
    good because some HTTP headers may be repeated (e.g. cookies).
  3. Support "output" HTTP methods like POST and PUT.

    committed
    This simply uses an optional dictionary entry 'entity. (This is NOT
    trying to support templating the request body for e.g. form POSTs. It
    is simply a way for a user of the wffi wrapper function to supply data
    "manually".)
Commits on Sep 13, 2013
  1. Sort requires

    committed
Commits on Sep 12, 2013
  1. LIB-ID should be based on LIB-NAME not lib-path.

    committed
    In other words
    
        (wffi-define-all "foo.md" ....)
    
    should expand to
    
       (define foo-lib (wffi-lib #<path:/path/to/foo.md>))
    
    as it did before my previous commit accidentally changed it, _not_ to
    
       (define /path/to/foo-lib (wffi-lib #<path:/path/to/foo.md>))
    
    Although when using `wffi-define-all` people aren't likely to need to
    refer to the lib itself, if they do need to, it should be the same
    short, predictable name as before.
  2. `wffi-define-all`: handle lib name simply. Closes #2.

    committed
    Automatically treat the `lib-name` as relative to the path of the
    source file using the `wffi-define-all` form. For example in
    `my-api.rkt` you can simply write:
    
        (wffi-define-all "my-api.md" <before> <after>)
    
    and if `my-api.md` is in the same directory as `my-api.rkt` it will
    just work.
    
    The contortions @takikawa had to use (for both phases 0 and 1) are no
    longer required. (To avoid breaking such code, the
    `current-markdown-files-path` parameter is still `provide`d, but it's
    a deprecated no-op.)
  3. Delete comment.

    committed
  4. Fix typo.

    committed
Commits on Jan 17, 2013
  1. Update Imgur example.

    committed
Commits on Jan 8, 2013
Commits on Dec 25, 2012
  1. Prose edits, formatting.

    committed
  2. Formatting.

    committed
  3. Refactor to simplify API clients.

    committed
    - Add macro `wffi-define-all` to define wrapper functions for all API
      functions in one go.
    
    - Provide duplicated helper functions from `client.rkt`.
Commits on Dec 19, 2012
  1. Move rx-proc out of api-func? struct.

    committed
    rx-proc was used only by servers, not clients, therefore it shouldn't
    live in the general api-func? struct.
  2. Add/use examples/server-example.md.

    committed
    The old example.md file went away when this project split out into
    webapi-markdown.
Commits on Dec 18, 2012
  1. Move Markdown format to its own, new project.

    committed
    The new project is webapi-markdown. It focuses on the description of
    the markdown format, as well as being a home for .md files for various
    services.
    
    That new project is not specific to Racket. Conceivably people could
    submit pull requests for various web services, and use those files wih
    parsers and web FFIs written in languages other than Racket.
    
    This original project _is_ specific to Racket. Although it still uses
    those markdown service files, the proper home for those files is their
    own project.
Commits on Dec 17, 2012
  1. Specify the service endpoint in the markdown file.

    committed
    - The endpoint (base URI for a web service) is specified in the
      markdown file by placing "Endpoint: <endpoint-URI>" on its own line
      anywhere in the first section. By convention the first section is an
      introduction to the service, so this reads naturally.
    
    - The old `api` struct -- which actually described a single API
      function -- is now called `api-func`.
    
    - The new `api` struct describes the entire service:
        - An endpoint
        - A listof api-func?
    
    - The `lib` arg to things like wffi-dict-proc is now a (new) `api?`
      struct (instead of a list of api functions). There is no longer a
      need to pass an extra `endpoint` arg.
    
    - Updated examples/ accordingly.
  2. Prose edits.

    committed
Commits on Oct 10, 2012
Commits on Oct 8, 2012
  1. Changes with comments.

    committed
  2. Improve comments.

    committed
Something went wrong with that request. Please try again.