From 88909914ca7f1055edcf2978563987edd1682d43 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lars=20D=C9=AA=E1=B4=87=E1=B4=84=E1=B4=8B=E1=B4=8F?= =?UTF-8?q?=E1=B4=A1=20=E8=BF=AA=E6=8B=89=E6=96=AF?= Date: Sun, 13 Mar 2011 01:29:00 +0100 Subject: spelling --- spore_description.pod | 24 +++++++++++----------- spore_implementation.pod | 24 +++++++++++----------- t/spelling.t | 52 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 76 insertions(+), 24 deletions(-) create mode 100644 t/spelling.t diff --git a/spore_description.pod b/spore_description.pod index 21e2752..4e258db 100644 --- a/spore_description.pod +++ b/spore_description.pod @@ -2,23 +2,23 @@ =head1 NAME -Spore (Specifications to a POrtable Rest Environment) Description Implementation +Spore (Bpecifications to a Brtable BEST Bnvironment) Description Implementation =head1 ABSTRACT -Spore is a specification for describing ReST API that can be parsed and used -automatically by client implementations to communicate with the descibed API. +Spore is a specification for describing REST API that can be parsed and used +automatically by client implementations to communicate with the described API. -This document describes how to write the description for a ReST API in +This document describes how to write the description for a REST API in order to be used with a SPORE Client Implementation. =head1 TERMINOLOGY =head2 API -An I is a ReST application that can exchange data with client -applications over http/https. It presents one or more method endpoints which -accept http requests with varying headers, parameters and body content to +An I is a REST application that can exchange data with client +applications over HTTP/HTTPS. It presents one or more method endpoints which +accept HTTP requests with varying headers, parameters and body content to perform specific operations. =head2 Client Implementation @@ -126,9 +126,9 @@ B begin with a <:>: "path" : "/statuses/public_timeline.:format" -XXX How can non-placeholder :foo's be included in the path? ie is there an escape mechanism? +XXX How can non-placeholder :foo's be included in the path? i.e. is there an escape mechanism? XXX What happens in this example if 'format' isn't listed in params/required? -XXX What happens if a parameter needs to be followed by a word character? ie can something like :{format}foo be used? +XXX What happens if a parameter needs to be followed by a word character? i.e. can something like :{format}foo be used? =head3 optional_params @@ -164,7 +164,7 @@ An optional list of accepted HTTP status codes for this method If C is specified then an exception will be thrown if the response status is not in the list. If C is not specified then an exception -will be thrown if the response status is not in the range 200 thru 299. +will be thrown if the response status is not in the range 200 through 299. XXX a global default_expected could be handy. @@ -183,11 +183,11 @@ An optional boolean to specify if this method requires authentication =head3 base_url -An optional base url for this method, if different to the default specified above. +An optional base URL for this method, if different to the default specified above. base_url: http://api.twitter.com/1/ -XXX might be nice to be able to express this as a relative url (relative to api_base_url) That could be handled at build time. +XXX might be nice to be able to express this as a relative URL (relative to api_base_url) That could be handled at build time. =head3 formats diff --git a/spore_implementation.pod b/spore_implementation.pod index ef06e68..8218651 100644 --- a/spore_implementation.pod +++ b/spore_implementation.pod @@ -2,12 +2,12 @@ =head1 NAME -Spore (Specifications to a POrtable Rest Environment) Client Implementation +Spore (Bpecifications to a Brtable BEST Bnvironment) Description Implementation =head1 ABSTRACT -Spore is a specification for describing ReST API that can be parsed and used -automatically by client implementations to communicate with the descibed API. +Spore is a specification for describing REST API that can be parsed and used +automatically by client implementations to communicate with the described API. This document describes what features are required in a Spore client implementation. @@ -18,7 +18,7 @@ implementation. =item API -An I is a ReST application that can exchange data with client +An I is a REST application that can exchange data with client applications over HTTP/HTTPS. It presents one or more method endpoints which accept HTTP requests with varying headers, parameters and body content to perform specific operations. @@ -65,13 +65,13 @@ the I to create the structure returned to the user. A I B provide a function or method (e.g. new_from_spec) to generate the specific API methods in the target system by reading the JSON string from a I (and -optionaly directly from the file itself). +optionally directly from the file itself). A I B also provide a method to enable or -disable spore middlewares at runtime. The order in which the +disable spore middlewares at run-time. The order in which the middlewares are enabled is the order in which the request will go through each middleware, and the inverse order in which the response -will go through each optional middleware postprocessing callback. It +will go through each optional middleware post-processing callback. It B also have a method to selectively enable a middleware or not for each method according to the method properties in the specification. @@ -83,7 +83,7 @@ specification. =head2 Middleware Each middleware B accept arbitrary initialization parameters. It -B provide a way to only conditionaly use a middleware (e.g. B). It +B provide a way to only conditionally use a middleware (e.g. B). It B also provide a function to which the request environment or an object containing it will be passed. The function can have 3 types of return values: @@ -104,8 +104,8 @@ made. The response is directly passed to the first stored callback in the chain. No further middlewares are used and no request is sent. Useful -if a middleware needs to shortcircuit the remaining of the chain, for -testing or caching purpose for exemple. +if a middleware needs to short-circuit the remaining of the chain, for +testing or caching purpose for example. =back @@ -145,7 +145,7 @@ C: The remainder of the request URL's path, designating the virtual "location" of the request's target within the API. This may be an empty string if the request URL targets the application root and does not have a trailing slash. It still contains the placeholders -which will be interpolated later with the params. +which will be interpolated later with the parameters. If this key is not empty, it B start with a forward slash (C). @@ -154,7 +154,7 @@ If this key is not empty, it B start with a forward slash (C). C: The undecoded, raw request URL line. It is the raw URI path and query part that appears in the HTTP C line and doesn't contain URI scheme and host names. It still contains the -placeholders which will be interpolated later with the params. +placeholders which will be interpolated later with the parameters. =item * diff --git a/t/spelling.t b/t/spelling.t new file mode 100644 index 0000000..7947839 --- /dev/null +++ b/t/spelling.t @@ -0,0 +1,52 @@ +use Test::Spelling; +my @stopwords; +for () { + chomp; + push @stopwords, $_ + unless /\A (?: \# | \s* \z)/msx; # skip comments, whitespace +} + +add_stopwords(@stopwords); +set_spell_cmd('aspell list -l en'); +all_pod_files_spelling_ok('.'); + +__DATA__ +## personal names +cuny +damien +franck +François +grunwald +leroux +Perrad + +## proper names + +## SPORE + +## computerese +API +CGI +JSGI +JSON +PSGI +URL's + +## other jargon + +## neologisms + +## compound + +## slang + +## things that should be in the dictionary, but are not +changelogs +metadata +middleware +middlewares +request's +undecoded +workflow + +## misspelt on purpose -- cgit v1.2.3