tags:

views:

74

answers:

3

Hi everyone,

I have a program that is supposed to interact with a web server and retrieve a file containing structured data using http and cgi. I have a couple questions:

  1. The cgi script on the server needs to specify a body right? What should the content-type be?
  2. Should I be using POST or GET?
  3. Could anyone tell me a good resource for reading about HTTP?

Thanks!

+1  A: 

If you just want to retrieve the resource, I’d use GET. And with GET you don’t need a Content-Type since a GET request has no body. And as of HTTP, I’d suggest you to read the HTTP 1.1 specification.

Gumbo
I'm actually writing the cgi script on the server. Does that need a body?
Jordan
@Jordan: That depends on – well – the content type you’re serving. ;-) What exactly is your “structured data”?
Gumbo
@Gumbo: this is sort of undecided for right now. I have an SQLite database sitting on the server side. My first thought would be to just serve up an SQLite database file, that has the query results. I'm pretty sure I can get my python cgi script to fill that database. I'm open to other suggestions though. Thanks!
Jordan
A: 

For (1) the Content-Type depends on the structured data. If it's XML you can use application/xml, JSON can be application/json, etc. Content-Type is set by the server. Your client would ask for that type of content using the Accept header. (Try to use existing data format standards and content types if you can.)

For (2) GET is best (you aren't sending up any data to the server).

I found RESTful Web Services by Richardson and Ruby a very interesting introduction to HTTP. It takes a very strict, but very helpful, view of HTTP.

Jim Ferrans
A: 
  1. The content-type specified by the server will depend on what type of data you plan to return. As Jim said if it's JSON you can use 'application/json'. The obvious payload for the request would be whatever data you're sending to the client.

  2. From the servers prospective it shouldn't matter that much. In general if you're not expecting a lot of information from the client I'd set up the server to respond to GET requests as opposed to POST requests. An advantage I like is simply being able to specify what I want in the url (this can't be done if it's expecting a POST request).

  3. I would point you to the rfc for HTTP...probably the best source for information..maybe not the most user friendly way to get your answers but it should have all the answers you need. link text

oneBelizean