I want to route all requests for a given resource to the same server. If a resource is created on a server, all following requests should be routed to the same server.
To be sticky on the url is not the problem, but how can I fill the stick-table from the first response?
Example:
Request:
POST /resources
{
"value": "bla"
}
Response:
{
"id": "1234",
"value": "bla"
}
GET /resources/1234
{
"id": "1234",
"value": "bla"
}
The second request should be routed to the same server, that handled the first request. Is there a way to get this done with haproxy?
Finally found a solution that works. I am posting this, in case somebody else is interested in the solution. The relevant lines are the following in section backend:
acl recources_path capture.req.uri,field(1,?) /resources
stick-table type string len 10 size 5M
stick match capture.req.uri,field(3,/)
# trying to parse the id out of the post response
stick store-response res.payload(0,0),field(2,{),field(4,\") if METH_POST recources_path
Especially the parsing of the response body seems to be not the intended way to use haproxy. Adding a response header with the resource id makes it much easier to handle the situation.
Related
I have an order resource on server. the url looks like http://example.net/order/1
the get method on above url will return whole order object like
{
"orderNo": "1",
"status": "order place",
"orderTimestamp": "2018-11-22 14:28:12",
"invoiceAddress": {
"salutation": "M",
"firstName": "Dieter",
"lastName": "Wolf",
"companyName": "",
"street": "Michaelkirchstr.",
"houseNo": "16",
"zipCode": "31604",
"city": "Raddestorf",
"countryIsoCode": "DEU",
"phone": "05763 82 60 80",
"email": "DieterWolf#armyspy.com"
},
"deliveryAddress": {}
"items": [
{
...
}
],
"returnItemsDetails": []
}
Now I wish to offer patch method on same api so one can update/add few details like delivery address. To update order detail one may request following request with patch http method on same order url
{
"deliveryAddress": {
"deliveryType": "CUSTOMER",
"salutation": "M",
"firstName": "Dieter",
"lastName": "Wolf",
"companyName": "",
"street": "Michaelkirchstr.",
"houseNo": "16",
"zipCode": "31604 ",
"city": "Raddestorf",
"countryIsoCode": "DEU",
"phone": "05763 82 60 80",
"email": "DieterWolf#armyspy.com"
}
}
My question is what should be there in response of patch request according to REST standard? or Is there any document where I can find about response data and format for REST api.
My question is what should be there in response of patch request according to REST standard? or Is there any document where I can find about response data and format for REST api.
According to RFC 5789 a successful response can return any success codes (i.e. 200 or 204). It should ideally also contain an ETag header to allow clients to track the current version for eventual consecutive requests (which is basically used for optimistic locking on the resources state).
The spec presents a 204 No Content sample as a patch consists, loosely speaking, of a set of instructions calculated by the client that a server should apply to transform the target resource to the desired state. So the client knows beforehand how the final result should look like and the server thus does not need to inform the client about it.
In case you want to return a 200 OK response I suggest returning a representation suggested by the Accept request header issued by the client (Content-Type negotiation) in order to avoid to force a client some predefined media type format it might not understand or reason further possibilities from.
If you need to apply unpredictable changes to a resource, i.e. based on some calculations done on the server side or include the payload to a certain predefined element (as probably done in your sample), RFC 5789 explicitly states that POST should be used instead of PUT or PATCH. Further note, that you could support application/merge-patch+json media format and its semantics defined in RFC 7386 to issue such a (sample) body as payload to a PATCH request and probably achieve your desired outcome, though.
My question is what should be there in response of patch request according to REST standard? or Is there any document where I can find about response data and format for REST api.
Patch is defined in RFC 5789. Section 2 demonstrates that one possibility is that you will return an updated representation of the resource:
A response to this method is only cacheable if it contains explicit freshness information (such as an Expires header or "Cache-Control: max-age" directive) as well as the Content-Location header matching the Request-URI, indicating that the PATCH response body is a resource representation.
But I wasn't able to find a specification for the more general case. So what I would suggest is that one interpret the specifications from RFC 7231 for PUT and DELETE also be applied to PATCH
a representation of the status of the action
I have a simple question that I cannot find the answer to.
My colleague is currently making a REST Api for an application, and we have a call that simply checks some information, and returns either true or false. However, we do not know what to call this type of request, as it does not retrive any resources or insert anyhing, it simply checks some information passed into the query. As far as I can understand, a GET has to retrive a resource, which this call isn't doing
What I understand is, resource in this case is either true or false. While calling the API you will expect response either true or false on the basis of information processed by API server (status will be always 200). So a GET method is still suitable for this case.
If you are not interested in response body and you want data like response code and header details, go with HEAD.
There might be a different way to express 'checking some information', and it's important to be a bit more specific as to what that means.
So lets take an arbitrary example. You're modelling blog posts and want to know if some blog post is set to 'draft'.
The 'draft' status can be its own resource, for example:
/posts/hello-world/is-draft
Doing a GET request on the is-draft resource can yield:
{
"is-draft": true
}
So to model arbitrary things as resources, the best way to think about this is to look at the result of the operation as the 'representation' and the 'thing you want to know' as the URI.
As far as I can understand, a GET has to retrive a resource, which this call isn't doing
Technically, it is retrieving a resource; see Fielding
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource.
The resource, in this case, might not load an entity in your data model, but that's OK. Not all resources have to.
Technically, I think what you have there is a "function"; all of the information that you need to compute the result is present within the URI itself? Which would mean that, if the client knew how to do the computation (and had the compute resources available), then the client would be capable of doing the work for itself.
But there's nothing wrong with having a resource that is "the result of a function".
In some API, you'll see predicates (functions that return true/false) implemented as resources that only exist (more precisely, only have "representations") if the evaluation is true.
GET /predicate?true
204 No Content
GET /predicate?false
404 Not Found
The fact that you don't need to consider the resources "state" to compute the correct response to the query is an implementation detail hidden behind the uniform interface.
It's hard to tell by the level of details you provided your question. But if you need to check whether a resource exists or not, you can use HEAD. It's identical to GET, but it doesn't return a representation in the response payload: it returns just the status code and the response headers.
Consider the following request HEAD request:
HEAD /postal-codes/10001 HTTP/1.1
Host: example.org
Content-Type: application/json
It should return 200 for a resource that exists:
HTTP/1.1 200 OK
Content-Type: application/json
And 404 for a resource that doesn't exists:
HTTP/1.1 404 Not Found
Content-Type: application/json
Depending on your needs, you could address it with POST, which can be seen as a catch all verb.
For example, consider the following request and responses:
POST /postal-codes/validation HTTP/1.1
Host: example.org
Content-Type: application/json
{ "postal-code": "10001" }
HTTP/1.1 200 OK
Content-Type: application/json
{ "postal-code": "10001", "status": "valid" }
HTTP/1.1 200 OK
Content-Type: application/json
{ "postal-code": "10001", "status": "invalid" }
I have a resource class. I need two APIs :
bulk create classes
create one class.
In the REST standards should I create 2 APIs:
/classes/bulk/ --- for bulk create
/classes/ --- to create one class.
This approach doesn't seem to REStFul to me or is it?
Is it more RESTful to use query param for this : /classes?type=bulk ?
Also, the processing logic and the response schema for 200 is different for the bulk and the non bulk call
This approach doesn't seem to RESTful to me or is it?
The URI spelling is not relevant in the REST architectural. Appending /bulk to the URI or not won't make your application more RESTful or not.
Alternatively to use /bulk in the URI, you could use the same URI for handling the creation of one or multiple resources. Consider that your resource is a message. Then you could have the following:
POST /api/messages HTTP/1.1
Host: example.org
Content-Type: application/json
{
"to": "John"
"content": "Hi"
}
POST /api/messages HTTP/1.1
Host: example.org
Content-Type: application/json
[
{
"to": "John"
"content": "Hi"
},
{
"to": "James"
"content": "Hey"
},
{
"to": "Sarah"
"content": null
}
]
It's also important to keep in mind whether the operation will be atomic or not. If one message contains invalid data, you may or may not reject the whole request.
If the operation is atomic, you can use 400 or 422 to report invalid data. If the operation is not atomic you could use 207 to report the result of the operation of each resource.
I am making a POST request to a REST API. This POST call succeeds on the first attempt with a HTTP status 200 and I get the correct result. However, when I make the next and subsequent calls, I get a HTTP 400 Bad Request Error. Why is it Bad Request when the previous call succeeded ?
When searching Bing, I found out that this could be related to submitting the same request. If I change some parameter in my payload, the call succeeds.
Any thoughts on what could be causing this? Am I missing something in request headers?
This is my POST Call.
POST http://myServer/v1.0/something/queries HTTP/1.1
Host: myServer
Authorization: Bearer some big token
Content-Type: application/json
Content-Length: 72
{
"field1": {
"Id": "12345"
},
"count": 1
}
In a lot of APIs, POST data is checked to confirm it is not a duplicate. This is important for some types of business logic such as ensuring there is only one user with some email address for example. In your request, I imagine it may be the "Id" field that is causing the HTTP 400 Bad Request since there is already an object with that "Id" in the system.
Every single resource I'va come across on Internet always describes very well what you can do with the GET operation, how it works and so on, bu it never explains the POST/PUT/DELETE and particularly the format of the data you pass in the HTTP body (I'm using JSON). It always says "you can make a post request and pass the appropriate data in the body".
I am struggling with what I can do and not. For example I want to know if it is possible to update one field of one entry by just sending the updated value, and not the entire object.
Is there any document that explains clearly the possibilities and limitations?
Thanks a lot.
Easy to read documentation is here: http://www.odata.org/developers/protocols
If you want all the dirty details and a strict language you can read this document: http://msdn.microsoft.com/en-us/library/dd541188(PROT.10).aspx
You can modify a value of a single property by sending a PUT request.
For example if you send a GET to this URL:
http://services.odata.org/(S(kupqbta5wqnfz2cln1qk052x))/OData/OData.svc/Products(0)/Name
And you request JSON (through an Accept header) the response will be:
{
"d" : {
"Name": "Bread"
}
}
The "d" wrapper is there only to avoid XSS attacks so that must not be included in the requests, but the rest stays the same, so if you then send a PUT request like this:
PUT http://services.odata.org/(S(kupqbta5wqnfz2cln1qk052x))/OData/OData.svc/Products(0)/Name HTTP/1.1
Host: services.odata.org
Content-Type: application/json
Content-Length: 20
{
"Name": "Meat"
}
It will update the property Name to value Meat. You can also send a PUT to the value itself, in which case the URL would end with $value (denotes the raw value of the property) like this:
PUT http://services.odata.org/(S(kupqbta5wqnfz2cln1qk052x))/OData/OData.svc/Products(0)/Name/$value HTTP/1.1
Host: services.odata.org
Content-Type: text/plain
Content-Length: 4
Meat
Note that this only works on primitive properties though.
The sample service on the odata.org allows you to make modifications (guarded by the session key in the URL), so can play with it there.
Google for the HTTP 1.1 specification.