Blogger Developer information: [WWW]

See also :


[MishaDynin] [SteveJenson] Here's how we see a sample post creation request in the new PieApi:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="" 

        <atom xmlns="">

       <feed xmlns="">
            <title type="text/plain" mode="escaped">Posting with the new API.</title>
            <content type="text/html" mode="xml">Hello, <em>new</em> world!</content>
            <title type="text/plain" mode="escaped">Posting a second entry with the new API.</title>
            <content type="text/html" mode="xml">Hey, you <strong>guys!</strong></content>



Please add them at the bottom of the page.

[AaronSw] I think using SOAP here is a mistake. Using HTTP Authentication (which is widely supported by tools) and putting the blogid in the URL seems like a much better system.

[DiegoDoval] Looks good. I wonder if the specific mention of title, content and issued tags implies that the call would be limited to those elements only. I think as far as the spec goes the Body should contain a WellFormedEntry, and then each server would be able to define what can be used and what can't.

[JoeGregorio] I don't see a problem with the SOAP envelope, as that may enable higher level tools like VS.NET to use the API more easily. I would like to see it be optional though. In addition, I would like to hear your thoughts on 'blogid' and authentication, for example, one way to refactor your example would be to put the blogid into the URI that this Entry is being posted to. Similarly, the name and password can be done via standard HTTP authentication, either Basic or Digest.

[ZhangYining RefactorOk] IIRC, Blogger does not support Categorization yet, but it seems to go into Echo. Would like to see how Blogger API handle Categorization if supported. Thanks.

[SteveJenson RefactorOk] Also, for editing a post, there shouldn't need to be a <blogid> element, you should be able to reuse the id element:  <id></id> 

[DaveWarnock RefactorOk] If a "DocumentLiteral" approach were taken to soap (which according the links is the preferred direction for the future), then would the differences between a SOAP and a REST server implementation pretty much disappear for the client? If I am correct then my concrete suggestions are

[MishaDynin RefactorOk] This is an example of how a post request might look like -- as indicated above, it's possible that both SOAP and HTTP/REST approach (with HTTP authentication) will be supported. In case of SOAP, extra information (such as request type -- newpost, deletepost, etc.) can be added to the SOAP header.

[DaveWarnock] Misha, I meant more like this.

POST /news/0101679 HTTP/1.1
Authorization: Basic gObBlEdYgOoK

<?xml version="1.0" encoding="UTF-8"?>
    <title type="text/plain" mode="escaped">Posting with the new API.</title>
    <content type="text/html" mode="xml"">Hello, <em>new</em> world!</content>

Will that work with a SOAP server working in DocumentLiteral mode? If so we have a very neat match between the feed and the edit api. Not only that but the server writer can choose to use SOAP or not.

[BillSeitz] Does Blogger intend to start offering feeds to non-Pro users? That seems more important to the ecosystem than the flavor of feed. (I'm pretty sure it's the main reason that BlogDex and DayPop don't even use RSS, but scrape front pages instead.)

[MishaDynin] Bill, offering feeds for non-Pro users is being discussed. Currently there are some technical and some non-technical problems with that. As for "containerization" -- Blogger users can create custom templates, and we don't control that.

[RahulDave] Must Each post have username and password in the header? What about using a cookie in the http header (non restian i know) or even in the soap header? Perhaps the cookie can be used in place of the password once the authentication is done. Blogger proper dosent require reuse of password again, just the 'remember me' cookie...

[GuilleBe] Is this missing an appkey?

ChrisJohnson: Like Aaron and Dave Warnock, I continue to be opposed to using SOAP as the default API. I suppose at this point in the discussion, and without an important URL attached to my name, my remarks will be ignored or just deleted. But as someone who has been programming RPCs and distributed computing since the 1980s, using everything from naked socket level programming to DCE to XML-RPC to SOAP, I feel I've got the experience to say that SOAP is gross overkill for this application. It's far too complicated, and the number of arguments about various technical aspects of it above on this page is supporting evidence for that statement. I used SOAP for a couple of different projects, and both interfaces were eventually discarded for simpler methods. In one case, going to XML-RPC made life much easier and still provided every necessary and nice-to-have feature, without the fragile, inefficiences of SOAP. Sorry about dumping a screed here, but I strongly believe that using SOAP will be a detriment to success in the long run. Regardless, whatever you all come up with I'll end up implementing in Drupal [WWW] Ok, let's use REST then...

CategoryArchitecture, CategorySyntax, CategoryApi