I would partially disagree with Milan’s suggestion of embedding the requested representation in the URI. If anyhow possible, URIs should only be used for addressing resources and not for tunneling HTTP methods/verbs. Eventually, specific business action (edit, lock, etc.) could be embedded in the URI if create (POST) or update (PUT) alone do not serve … Read more
It should be put in the HTTP Authorization header. The spec is here https://www.rfc-editor.org/rfc/rfc7235
The reason you get no hard answers is because there is no hard RESTful standard. So I can only suggest that you create a hard standard and stick to it within your own APIs I used this as a guide for RESTful services http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api It says respond with a 204 status and an empty body … Read more
Forgive the flippancy, but if you are doing REST over HTTP then RFC7231 describes exactly what behaviour is expected from GET, PUT, POST and DELETE. Update (Jul 3 ’14): The HTTP spec intentionally does not define what is returned from POST or DELETE. The spec only defines what needs to be defined. The rest is … Read more
Why aim for a RESTful design? The RESTful principles bring the features that make web sites easy (for a random human user to “surf” them) to the web services API design, so they are easy for a programmer to use. REST isn’t good because it’s REST, it’s good because it’s good. And it is good … Read more
Returning the new object fits with the REST principle of “Uniform Interface – Manipulation of resources through representations.” The complete object is the representation of the new state of the object that was created. There is a really excellent reference for API design, here: Best Practices for Designing a Pragmatic RESTful API It includes an … Read more
Using the -X flag with whatever HTTP verb you want: curl -X PUT -d argument=value -d argument2=value2 http://localhost:8080 This example also uses the -d flag to provide arguments with your PUT request.
It’s times like this (when there is no real explanation for the problem) that I throw in an ExceptionMapper<Throwable>. Often with server related exceptions, there are no mappers to handle the exception, so it bubbles up to the container and we get a useless 500 status code and maybe some useless message from the server … Read more
Using the Chrome Developer tools to capture the payload of a Queue action in the web UI, I’d hazard a guess the format you’re looking for is: POST https://dev.azure.com/jessehouwing/6484ebc3-af16-4af9-aa66-6b3398db7214/_apis/build/builds { “queue”: { “id”: 27 }, “definition”: { “id”: 53 }, “project”: { “id”: “6484ebc3-af16-4af9-aa66-6b3398db7214” }, “sourceBranch”: “refs/heads/master”, “reason”: 1, “demands”: [], “parameters”: “{\”system.debug\”:\”true\”,\”DefinedVariable\”:\”Override Value\”}” }