Hi Stephan,
I love JSON web services, and I really like the idea you've presented. I've
often wished I could display Fossil ticket reports in a more flexible way, and
the changes you propose would give me that. I look forward to seeing this
progress.
In my experience writing both JSON web services (in Perl), and the consumers of
those services, sometimes you can get output that contains not only a JSON
string, but stray newlines or other (debugging?) output. I'm sure you and
Fossil would never do such a thing, right? Then again, anything's possible
(useful debugging output, ISP-modified content, etc.)
This makes it difficult to parse the JSON string out of the response content.
I have found that surrounding the JSON string with a predefined tag (I've
standardized on <TJSON></TJSON>; because my company's name starts with "T", but
Text-JSON works, too) makes it easy to extract the JSON string from whatever
else might be in the response content.
This also helps deal with either a raw JSON array ([...]) or the more common
object ({...}) without having to test for both patterns.
Also, as part of what I've come to call the "TJSON" format, the JSON always
includes a status object where a result code and message can be transmitted.
So, in TJSON, the minimum response would always look like:
<TJSON>{"RC":{"code":0,"msg":"Success"}, "fossil":{...}}</TJSON>
This makes it easy to communicate app-level errors/messages because the
resulting object always has the RC property to hold a numeric code, and an
error description string. The consumer can always rely on being able to check
RC.code to see if there was an error (and capture the error string to do with
as he sees fit).
All of the other properties of the JSON object are arbitrary based on the
requirements of the requested service method.
-Clark
________________________________
From: Stephan Beal <[email protected]>
To: fossil-users <[email protected]>
Sent: Thursday, September 8, 2011 7:58 PM
Subject: [fossil-users] First Fossil/REST proto-demo
It's not much, but it's a start:
Here's the code (not counting 10 or 12 lines of infrastructure-level code):
/*
** WEBPAGE: /json
**
*/
void json_page_top(void){
Blob buf = empty_blob;
cson_value * json = NULL;
cgi_set_content_type( cson_cgi_guess_content_type(&g.csonCgi) );
json = cson_cgi_env_get_val( &g.csonCgi, 'e', 0 ); /* the $ENV vars map */
blob_zero(&buf);
cson_output_Blob( json, &buf, NULL );
cgi_set_content(&buf)/*takes ownership of the buf memory*/;
}
When visiting it with the path /json/a/b/c that generates:
Headers:
1. Cache-control:no-cache, no-store
2. Connection:Keep-Alive
3. Content-Encoding:gzip
4. Content-Length:650
5. Content-Type:application/json; charset=utf-8
6. Date:Fri, 09 Sep 2011 02:49:37 GMT
7. Keep-Alive:timeout=15, max=100
8. Server:Apache/2.2.16 (Ubuntu)
9. Vary:Accept-Encoding
10. X-Frame-Options:SAMEORIGIN
Content:
{ "HTTP_HOST":"whiki", "HTTP_CONNECTION":"keep-alive",
"HTTP_USER_AGENT":"Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.30 (KHTML,
like Gecko) Chrome/12.0.742.124 Safari/534.30",
"HTTP_ACCEPT":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"HTTP_ACCEPT_ENCODING":"gzip,deflate,sdch",
"HTTP_ACCEPT_LANGUAGE":"en-US,en;q=0.8",
"HTTP_ACCEPT_CHARSET":"ISO-8859-1,utf-8;q=0.7,*;q=0.3",
"PATH":"/usr/local/bin:/usr/bin:/bin",
"SERVER_SIGNATURE":"<address>Apache/2.2.16 (Ubuntu) Server at whiki Port
80</address>\n", "SERVER_SOFTWARE":"Apache/2.2.16 (Ubuntu)",
"SERVER_NAME":"whiki", "SERVER_ADDR":"127.0.1.1", "SERVER_PORT":"80",
"REMOTE_ADDR":"127.0.1.1",
"DOCUMENT_ROOT":"/home/stephan/cvs/fossil/whiki/website", "SERVER_ADMIN":"[no
address given]",
"SCRIPT_FILENAME":"/home/stephan/cvs/fossil/whiki/website/cgi-bin/fossil.cgi",
"REMOTE_PORT":"52331", "GATEWAY_INTERFACE":"CGI/1.1",
"SERVER_PROTOCOL":"HTTP/1.1", "REQUEST_METHOD":"GET",
"QUERY_STRING":"", "REQUEST_URI":"/cgi-bin/fossil.cgi/json/a/b/c",
"SCRIPT_NAME":"/cgi-bin/fossil.cgi", "PATH_INFO":"/json/a/b/c",
"PATH_TRANSLATED":"/home/stephan/cvs/fossil/whiki/website/json/a/b/c",
"PATH_INFO_SPLIT":[ "json", "a", "b", "c" ]
}
i might have to fight with fossil a bit over who gets to parse the POST data
from stdin, since fossil will, by default, consume stdin before the JSON CGI
bits get the chance to (and if they do it first then Fossil can't do it). But i
don't need to solve that until i write a request type which needs POST, so that
can wait.
-- ----- stephan beal
http://wanderinghorse.net/home/stephan/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
