Question: do we really need a separate method of logging in, or would it be better just to use the existing HTTP basic/digest authentication options?
OTOH, it would be useful to have a REST-ful user, e.g: for user FredBloggs the URL /users/FredBloggs contains
<?xml version="1.0"> <user name="FredBloggs" email="email@example.com"> <password>cheesypoofs</password> <options> <home lat="0.0" lon="0.0" /> ... </options> </user> </xml>
and the user (properly authenticated, of course) can PUT a changed file back in place to change options/passwords.
What do you think? --Matt 17:27, 20 Jul 2005 (BST)
Probably a FAQ, but I can't find it anywhere, how does one gain user authentication details? --TacoJim 15:21, 22 Mar 2006 (UTC)
What is this?
Perhaps someone who has a clue could write a few introductory words about what REST is and who needs it? --LA2 19:31, 20 Jul 2005 (BST)
Re: What is this?
In short, the idea is that you grab whole object state in a single transfer, e.g: a web page is grabbed with a single "GET" command, rather than several RPC-style getPageTitle(), getPageHeader(), getPageBody(), etc... This, according to one of the guys who wrote HTTP, makes the client and server simpler. --Matt 20:22, 20 Jul 2005 (BST)
Anonymous GET methods?
Currently all methods (GET, DELETE and PUT) require authentication. How easy would it be to allow GET methods to work without authentication? I have a number of tools that I'd like to use to GET some data for rendering, but they all fall at the first fence because they don't do authentication. 80n 17:56, 21 Mar 2006 (UTC)
- Not sure if this would help, but have you tried cURL? According to the Wikipedia article, cURL does some authentication methods. Teratornis 14:19, 22 Jul 2006 (BST)
Does SQL Server Refer to MySQL?
In the General Notes section, I added Wikipedia hyperlinks to some of the jargon terms, so people who don't already know them can see what they mean. The term SQL server was ambiguous. I linked it to MySQL. I'm guessing OSM uses MySQL because I see it mentioned in Setting up a test server. If I guessed incorrectly, please fix my hyperlink. Teratornis 14:19, 22 Jul 2006 (BST)
The OSM server sends and receives UTF-8 encoded XML data (at least, that is the goal - we're not entirely there yet). Here is a summary of a discussion we had about encoding.
XML documents are, unless specified otherwise, in UTF-8. This is a way of encoding unicode characters using just 8-bit bytes. Sometimes it requires several UTF-8 octets (bytes) to represent a character.
Characters below 0x80 are represted as themselves. UTF-8 only differs from ASCII for characters >= 0x80.
Example: one octet (byte) with the value 0xc3 followed by one octet with the value 0xbc
In UTF-8 this encodes the Unicode codepoint 0xFC (the German letter "ß"), 2 octets are used. Some codepoints require 3, 4 or even more octets to encode into UTF-8.
The German "ß" can also be encoded as
ü or ü
All 6 octets of this entity (the "&", the "#", the "x" etc.) are ASCII-like characters (i.e. < 0x80).
The number encoded (in hex if you have the 'x', in decimal if you omit the 'x') will be interpreted by an XML parser as a character code point in ISO/IEC 10646. (In this case, the German letter ß).
An XML document can use either of these encoding methods in the same document. The entities ALWAYS encode Unicode codepoints, even if the XML stream isn't in UTF-8.
The fact that many values used in the entities look like an HTML-ized version of the latin-1 encoding (ß is 0xFC (8 bits!) in latin-1) is not excatly coincidental, as Unicode is based upon both ASCII and latin-1.
Description of DELETE for various types should say what happens if you try to delete an object which is included in a higher level object. E.g., if you delete a node which is part of a segment or a segment which is part of a way. EdD 00:18, 5 September 2006 (BST)
- When using a database engine with functions for foreign keys, the database will return an error if you would try that automatically. Mysql versions 3, 4 and 5 using the MyISAM engine do not support foreign keys. Therefore this type of checking still needs to be done in the API code... --Lambertus 11:08, 21 March 2007 (UTC)
The API is the way to go if we want to see more unexpected 3th party implemenatations with OSM, therefor using the data we all gatherd and making OSM more visible on the web. The current API is very "development" oriented, adding and removing nodes, finding specific node ID's. Wouldn't it be nice to have a whole other view on the data like finding a streetname in some city and return a PNG with a rendering for that region, looking for all cities in a given country, transforming GPS coordinates to street names,... Don't know if I make myself clear but this kind of API would allow me (and others) to use the OSM data in a whole other way and create things Google Maps or Yahoo maps is currently missing (e.g. in Belgium you can not search for an address in Google Maps). In my opinion this could create a quick win and add whole new possibilities to OSM without minimal efforts: "I need a map of my small local store but Yahoo Maps doesn't cover my region and Google Maps has some error in my neighbourhood", great, improve OSM by contributing or correcting data and integrate it in your website with the API! It's this kind of API I'm currently missing. --Cimm 13:50, 20 November 2006 (UTC)
Currently, every update (new, change, delete) on nodes/segments/ways are processed with individual requests. This method has some disadvantages:
- Each request to the webserver requires several steps which have no direct relation the the update itself (logging in, handling results, etc.).
- While uploading multiple changes it introduces delays between the updates which are inevitable (e.g. internet roundtrip delays).
- (add more;-))
These disadvantages can be solved using a transaction based interaction in which multiple updates are joined into a single request to the server. The server can then update the db more efficiently (by joining updates, inserts etc.), check the validity of the new data as a whole and return a single result code for the entire transaction. By adding - not replacing - transaction the current clients can still function, but updates/new clients can profit from the aforementioned advantages. --Lambertus 10:56, 21 March 2007 (UTC)