I should maybe add: the deletion uses C4:DelBiblio, so it will fail if the biblio has any items associated with it. This is the intended behaviour.

Petter, I like your patch. As far as I understood, it is used that PUT is used to update an object instead of POST.

http://www.ibm.com/developerworks/webservices/library/ws-restful/
http://en.wikipedia.org/wiki/Create,_read,_update_and_delete

I haven't checked what previous behaviour was in the svc endpoint, though.

You're right Tomás, PUT would be the appropriate HTTP verb to use when updating a resource. So a better layout of the /svc endpoint could be:

  GET  /svc/biblio/{biblionr}  -> fetch record
  POST /svc/biblio             -> create record
  PUT  /svc/biblio/{biblionr}  -> update record

However, that would be a breaking change for people allready using POST /svc/new_bib for creating records, and POST /svc/biblio/{biblionr} for updating records.

Do you know how many actually are using the svc API, and how? Cait mentioned on IRC they use it for ILL.

Incidentaly, if there is a momentum for expanding Koha's HTTP APIs, I think Biblibres koha-restfull is a much better basis to build on:
http://git.biblibre.com/biblibre/koha-restful/tree/master

It's well structured, easily extendable, has clean code and tests. I asked Joubo about their plans for it, and he said they don't plan for it to get included into Koha master (but they use it themselves and will continue to maintain it)

IMO it would be an interesting direction for Koha to go if it would expose most of the functionality through REST APIs, and make the templates use the APIs, instead of calling functions directly before rendering, or even worse, custom raw sql queries..
The benefits of this apprach would be:
* More content could be fetched asynchronously (we allready see a push in this
  direction, with recent ajax+datatables enhancements)
* Because of this, pages would load faster (even if not all data is populated
  immideatly) and, more importantly, the browser could cache many of the 
  requests, resulting in less trips to the database.
* I also think that this approach makes sense from an architectural point of
  view, and could lead to better structured and more maintainable code.

Created attachment 32736 [details] [review]
[PASSED QA] Bug 12590 - Support deletion of biblio in svc API

The /svc endpoint allows you to create and update biblio records.
This patch extends it so that it is also possible to delete a biblio.

Test plan
* Create a new biblio by sending a POST request to /svc/new_bib with a
  marcxml record as request body. Note the biblionumber it gets assigned.
* Make some changes to the marcxml record, and update it by sending
  a POST request to /svc/bib/{bibilonumber}
* Observe that the changes are persisted on the biblio record.
* Now delete the bilblio by sending a DELETE request to
  /svc/bib/{biblionumber}
* Observe that the biblio is indeed gone from the db.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works as described and passes tests and QA script.
I tested using curl for a record with and one without items:

curl -X DELETE 'http://localhost:8080/cgi-bin/koha/svc/bib/2' --cookie /tmp/svc.cookies
<?xml version='1.0' standalone='yes'?>
<response>
  <error>This Biblio has items attached, please delete them first before deleting this biblio </error>
</response>

curl -X DELETE 'http://localhost:8080/cgi-bin/koha/svc/bib/3' --cookie /tmp/svc.cookies
<?xml version='1.0' standalone='yes'?>
<response>
  <status>OK, biblio deleted</status>
</response>

The deletion is processed correctly and the indexes are updated.

Patch pushed to master.

Thanks Petter!