We wanted to avoid needing to spell out diffing mechanisms for every conceivable format in the core spec.
The trick around this to technically remain spec compliant, while also not surprising consumers of the WebSub API, is to say that your WebSub-enabled URL returns only the latest item. That way you can send just the one <article>
or whatever, and it still counts as "sending the full contents of the URL". In practice, it's fine to do this as long as the page you're sending has a concept of multiple items in a list, and if your consumers are ready to handle arbitrary numbers of items.
It worked for me, but of course I had to set the authorization endpoint in the settings back to https://indieauth.com/auth
.
If you have the authorization endpoint set to the built-in one, then it would be kind of stuck in a weird state. Which brings me to another point. How do I know what the URL for the built-in authorization endpoint is? Right now if I change it to indieauth.com, then I have no way of knowing what to change it to to make it go back. Blanking out the value just stores a blank value which breaks it. Can you make it revert to the default built-in URL if a blank value is saved?
Was able to reproduce this after carefully reading the other thread. The key is this: https://github.com/snarfed/wordpress-micropub/issues/104#issuecomment-359267767
If you save the writing settings page, it writes a blank value for micropub_default_post_status
to the database, so then the get_option
call later will return the blank value instead of the default.
I have no strong opinion here, 501 arose from discussion on the IWC Slack.
My API experience falls into REST and deep-stack buckets. Micropub is lighter weight than any non-REST protocol I've used or implemented over HTTP, so it "feels" right for it to act RESTy.
To defend my recommendation, if it's not appropriate to use HTTP codes, why does the spec call for the use of 4xx codes, rather than replying with a 2xx that includes error details?