What do you mean with REST?

[mro]

I understand REST as

1. use HTTP verbs
2. use URIs like in DELETE /posts/Shsmbw or POST /posts/
3. use HTTP status codes and reason phrases as in http://stackoverflow.com/questions/942951/rest-api-error-return-good-practices/34324179#34324179

[ArthurHoaro]

Also being stateless

The client–server communication is further constrained by no client context being stored on the server between requests.

For the nice URIs, there is an open ticket, shaarli/Shaarli#508. I'm not sure we should include it here.
Using DELETE /?do=api&xx=posts&id=Shsmbw instead of DELETE /api/posts/Shsmbw is less clean, but not a very big deal.

[mro]

is less clean, but not a very big deal

indeed, but if do likewise with the other two, it's not much REST left except marketing waffling.

[ArthurHoaro]

Not really because in the end it's the exact same thing if routes are properly written.
I don't mind using clean URL for the API right now, but it needs to be well documented for nginx and eventually lighthttpd (Apache redirection can be done with .htaccess).

[virtualtam]

Using DELETE /?do=api&xx=posts&id=Shsmbw instead of DELETE /api/posts/Shsmbw is less clean, but not a very big deal.

it's not much REST left except marketing waffling

Isn't REST itself already a marketing-swag-friendly term for designating a mere HTTP API dealing with JSON data?

use URIs like in DELETE /posts/Shsmbw or POST /posts/

Resource-centric routes help defining an API's endpoints, and can be assumed as a prerequisite, as this is how most API consumers will expect a RESTful service to be defined.

It is quite representative of the overall logic; for a given resource type, there should be:

• one API endpoint (route)
• one HTTP server/service view performing the actual action (depending on the HTTP verb, parameters and JSON payload)
• one client function/method to emit queries altering this type of resource (and handling response statuses)

This involves enhancing Shaarli's router to handle such URLs, at least for the newly introduced API endpoints.

[ArthurHoaro]

This involves enhancing Shaarli's router to handle such URLs, at least for the newly introduced API endpoints.

Depends how we handle redirection. For example, this won't require any work on the router, but requires more complex redirections (simplified):

/api/(\w+)/(\w+)\?(.*) --> ?do=api&request=$1&param=$2&$3

While this does:

/api/(.*) --> ?do=api&request=$1

Maybe a good way to have cleaner URIs for the API without being bother with web servers configurations is to do something like this:

DELETE ?do=api&q=/links/Shsmbw
POST     ?do=api&q=/links
GET       ?do=api&q=/links&limit=20

What do you think?

EDIT: actually, none requires work on the Router, but the way the API code will handle parameters.

[mro]

rather DELETE api-v1.php?noun=links&id=Shsmbw – or is there a reason against a separate api.php that includes only the bare minimum of other code? E.g. no html render, no plugin stuff etc.)? &q= may be neat when it comes to searching.

[mro]

let's first get #6 sorted. Will ninja-re-open later if appropriate.

[ArthurHoaro]

I'd prefer to keep one entry point (index.php), to have in one place:

• server settings initialization
• plugin loading
• configuration loading
• router definition

It would avoid duplicating too much stuff.

Note that the template engine, RainTPL is loaded only if we need it.
Also, performance could be improved later with proper class autoloading.