Would like to know whether is it possible to request multiple cabin class fare in a single request.
i.e. I would like to request fare for Economy, Business and First cabin Class in a single request.
Thanks.
You can try sending multiple FareParameters inside FlexibleFares:
OTA_AirLowFareSearchRQ/TravelPreferences/TPA_Extensions/FlexibleFares/FareParameters
There is a Cabin element under FareParameters, with a Type attribute that allows you to select the cabin you want.
Related
I'm looking for a best way for implementing an endpoint of REST-full application that will be responsible for creating a new library orders. Let's assume that I have the following resources.
If I want to get all books of a particular author I can use the next endpoint:
HTTP GET
api/books/author/123
If I want to fetch all orders of a particular book I can use the endpoint provided below:
HTTP GET
api/books/456/orders
My question is what will be the most suitable URL and a request model for an endpoint that will create orders?
From my perspective it can be
HTTP POST
api/books/456/orders
And one more question. Is it a good practice in REST to use request models like CreateOrder? If I want to create a REST-full web application can I use the following request model:
class CreateOrder
{
AuthorId: number;
BookId: number;
ClientId: number;
}
Sometimes it makes me confused. Should request models look like our resources or not?
Let's assume that I have the following resources.
Your "resources" look suspiciously like "tables". Resources are closer to (logical) documents about information.
what will be the most suitable URL and a request model for an endpoint that will create orders
For the most part, it doesn't matter what URL you use to create orders. In a hypermedia application (think HTML), I'm going to submit a "form", and the meta data associated with that form are going to describe for the client how to compose a request from the form data.
So the human, or the code, that is manipulating the form doesn't need to know anything about the URL (when is the last time that you looked to see where Google was actually sending your search?)
As far as general purpose web components are concerned, the URL/URI is just an opaque identifier - they don't care what the spelling means.
A thing they do care about is whether the spelling is the same as something that they have cached. One of the consequences of a successful POST /x message is that the cached representation(s) of /x are invalidated.
So if you like, you can think about which cached document should be refreshed when an order is created, and send the request to the identifier for that document.
Should request models look like our resources or not?
It's not necessary. Again, think about the web -- what would the representation of create order look like if you were POSTing form data?
clientId=1&bookId=2
or maybe
bookId=2&copies=3
If the "who is creating an order" is answered using the authorization headers.
In our HTTP requests and responses, we are fundamentally sending message representations - sequences of bytes that conform to some schema. There's no particular reason that those sequences of bytes must, or must not, be the same as those we use elsewhere in the implementation.
Your end-point does not need to always start with /books. You can introduce another end-point /orders for creating or getting orders. So , to create an order , you can :
HTTP POST
api/orders
And does the 'request model' that you mean is the HTTP request body structure ? If yes, it does not need to be 100% match with your back-end persisted/domain model. Just include enough parameters that the server needs to know in order to create an order. (e.g. Include bookId rather than the whole book object etc.)
BTW , to get all books for a particular author , it is more common to use query parameter such as :
HTTP GET
api/books?authorId=123
What you are doing is not REST, it is CRUD over HTTP. REST does not care about your URI structures and resources are very far from database tables. If CRUD is all you need, then download a CRUD generator library https://github.com/search?q=crud+generator&type=Repositories, which will generate all the upper and you won't need to write it manually.
I've created a REST API. According to my design, we have to store user's blood sugar level per daily basis.
The problem is:
I want to use single endpoint for the insert and the update operations
I don't want to use primary key of the blood-sugar resource in the URI because i want to store only the last value for a single day.
For example if I make this call
POST https://{host}/users/1/blood-sugar/
{
"measureDate": "2019-05-04",
"bloodSugarLevel": 86
}
It will create a blood-sugar resource and the database will assign and ID (let's say ID=333)
It's OK until here.
Then, I want to be able to make a second request with same date but different blood sugar level. As a result, i want to the backend should find the previous blood-sugar resource (with ID=333) and update the bloodSugarLevel field, because we already have a record for this day (2019-05-04). I don't want to send ID=333 in the request body or URI.
POST https://{host}/users/1/blood-sugar/
{
"measureDate": "2019-05-04",
"bloodSugarLevel": 105 # only this value is different
}
My question is:
Is there any way to achieve this (or similar) result with REST? You can offer me to change the VERB or the URI or the request body.
Note:
If I was doing this with WCF or similar thing, only single method would satisfy the all my requirements. For example: CreateOrUpdateBloodSugarLevel(int userId, DateTime measureDate, int bloodSugarLevel)
Thanks.
Is there any way to achieve this (or similar) result with REST?
Just POSTing the updated value to the same endpoint is fine.
Think about how you would do this on the world wide web. You would visit a website, and would load some form, containing a text field for date, a text field for bloodSugarLevel, and a submit button. That would POST the message to the web server, and your browser would get back some response.
Note that, as a client, we really don't care whether the server appends the new message into a list, or upserts the message into a map, or does some clever thing with an RDBMS or a graph database. Those are implementation details; part of the point of having a uniform interface is that the interface means that the clients (and generic components) don't really need to know what is happening.
Another application protocol that could work would be to treat bloodSugarLevel as a document that users can edit locally. That way, a client could just use any HTTP aware editor to do the right thing.
GET /users/1/blood-sugar/
200 OK
{
"measureDate": "2019-05-03",
"bloodSugarLevel": 90
}
PUT /users/1/blood-sugar/
{
"measureDate": "2019-05-04",
"bloodSugarLevel": 86
}
204 No Content
PUT /users/1/blood-sugar/
{
"measureDate": "2019-05-04",
"bloodSugarLevel": 105
}
There are some semantic advantages to using PUT when the network is unreliable; because the server agrees that the message handing will be done idempotently, clients can respond to a timeout waiting for an acknowledgment by repeating the send.
Semantically, PUT means "upsert", but the underlying implementation doesn't have to be an upsert. We're only making promises about the semantics that the client can expect.
I have two entities Hotel, Merchant where each merchant can have many hotels. Right now I am having an api endpoint like this:
/api/v1/merchants/{id}/hotels/{id}
But I was thinking what is wrong with this semantics:
/api/v1/hotels/{id}
The later one is short too.
In my experience, the latter is preferable because it gives you more flexibility later. In six months somebody's going to say "Hey, I want to be able to look up all the hotels in Agraba". The first URL scheme makes that painful - you need to add a new endpoint. The second URL scheme supports that with a query parameter: GET /hotels?location=Agraba.
You may want to keep /merchants/{id}/hotels as a collection endpoint so you can POST/DELETE to add/remove hotels from a particular merchant.
In REST, each URL should uniquely identify a single resource.
So if the hotel's id is globally unique, then sure, there's no problem in using the shorter link. If however hotel id 1 means something different for merchant 1 than for merchant 2, then you ought to stick with the first URL (basically a unique composite key).
When resource has a unique identifier it is retrieved:
/building/{building_id}
But what if "event" resource is described using building_id and floor_id parameters. How to name RESTful endpoint that is meant to retrieve present events?
To be precise, "event" resource has a unique identifier (id). Combination of building_id, floor_id ought to return present event in a particular location.
But what if "event" resource is described using building_id and floor_id parameters.
Is it? I recommend this:
If
GET /events/{id}
returns one event and
GET /events
returns all events, then
GET /events?building_id={building_id}&floor_id={floor_id}
returns the list of (possibly only one) event(s) at the combination of building_id and floor_id.
This looks like the often used filter-or-search-a-collection-resource-pattern.
Apart from the solution by Lutz, in case if you dont want them to be query parameters.
Assuming, from the name as it looks, floor_id is part of building_id , so if the event resource is defined as combination of both , it can be like
/event/{event_id}/building/{building_id}/floor/{floor_Id}
I'd start by trying to think what resource owns what. Obviously, buildings own floors (knock the building down, the floor is destroyed!) so that's a relationship that maps nicely to a sub-resource, but do events own buildings or do buildings/floors own events? No? Then we relate these by links. (A floor might have a current event concept as something it owns, but that's really a link to an event, not an event per se.)
/building/{building_id}
/building/{building_id}/floor/{floor_id}
/building/{building_id}/floor/{floor_id}/current-event --redirect--> some event
/event/{event_id}
The event probably should have hyperlinks to the building and floor which it involves. Going the other way, if there's no current event for a floor, fetching the …/current-event will result in a 404, and if there is an event, a 303 redirect will say which it is. (You might also want to make the record for the floor itself contain a true link to the event, as well as a convenience lookup sub-resource.)
A good RESTful application looks an awful lot like a densely linked website. Use the power of links and redirects!
I'm converting a SOAP based RPC style "web service" to a JSON based REST web service using ASP.NET Web API.
Methods such as AddXYZ / UpdateXYZ / RemoveXYZ map cleanly to the HTTP verbs for POST/PUT/DELETE. Are there any best practices/guidance for mapping typical RPC style operations such as "ExecuteXYZ" or "AssignXYZ" style methods to it's REST counterpart?
My take is that such operations would map to corresponding URL addressable resources such as "ExecuteXYZRequest" and "AssignXYZRequest"
http://myhost/myservice/ExecuteXYZRequest
http://myhost/myservice/AssignXYZRequest
A request to execute "ExecuteXYZ" would then translate to a POST operation.
Getting the submitted request would translate to a GET(typically would be used to get the status of the submitted request).
http://myhost/myservice/ExecuteXYZRequest/1 <--- 1 is the ID of the request
Cancelling the request(assuming it's cancellable) would translate to a DELETE
POST would not really map to anything.
Does the above sound like a reasonable REST implementation or am I totally off in my thinking here?
Thought/guidance much appreciated.
UPDATE
Here is the specific example I'm trying to model:
A many to many relationship between a Contact and an Event entity. What would be the best way to model the membership of a Contact to an Event as a REST resource such that a Contact can be added/ removed from an Event. In the RPC land This would be a method such as "AssignContactToEvent" which takes the IDs of both entities and set up the relationship between these two. How can this be modeled naturally in REST as a resource. I recall that there is a concept of links and "rel" but cannot find a concrete practical example illustrating how to model something like this using Web API
Question is whether it makes sense for the RPC methods to map to REST
resources as indicated in the post
In a nutshell; no, it doesn't make sense to map methods to resources in the way you describe :)
In order to successfully "do REST" we have to think a little differently, and abandon all thoughts of RPC and CRUD-operations; these are really rather limiting once you embrace being RESTful!
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. A resource is a conceptual mapping to a set of entities, not
the entity that corresponds to the mapping at any particular point in
time.
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
A method or action/verb is then not a resource, so it has no place in a URI -- unless of course you're building an application that allows people to create their own methods, which would be rather unusual!
Taking your specific example for a contacts and events relationship, it's important to understand that your 'AssignContactToEvent' is an action that happens under the Web-API layer and cannot be modelled RESTfully; I hope this will become clear in the course of the following examples :)
First we need some good resources to model a list of all Contacts, and a list of all Events:
/contacts
/events
These resources model an individual Contact or Event identified by an ID-token:
/contacts/{contact_id}
/events/{event_id}
The users of your application want to know who is involved in a particular Event, so we need a resource that models a list of the Event's participants:
/events/{event_id}/participants
When we want to add a Contact to an Event, we could POST a minimal Contact-representation (containing just the Contact-ID) to the Event's participants-list:
POST /events/{event_id}/participants/ HTTP/1.1
Content-Type: application/json
{'id': {contact_id}}
To remove a Contact from an Event:
DELETE /events/{event_id}/participants/{contact_id} HTTP/1.1
Your application-users also want to see at-a-glance the Events a Contact is participating in, so you need another to resource to model this:
/contacts/{contact_id}/events
Similarly, you can now GET a list of Events for the Contact, and assign Events using POST:
POST /contacts/{contact_id}/events/ HTTP/1.1
Content-Type: application/json
{'id': {event_id}}
The important point to take onboard is that whenever you need to model something new, you create a resource. The details of how you store the properties and relationships of data-objects are abstracted away behind a Web-API. Indeed, the data-storage technology might change in future, say from relational to object-store, or you change your programming language or framework, but in all cases your URI's (and Web-API) remain the same. REST and HTTP are designed to endure well-beyond the technologies that run under-the-hood.
As a final example of creating new resources, consider a resource that models a list of Contact's who have an organiser-role:
/events/{event_id}/organisers
or this one that models the list of Events that a Contact is organising:
/contacts/{contact_id}/events-organised
If you have a authentication-system, then you might want to see the events you are attending:
/my-account/events
I hope this helps to clarify the purpose of a Web-API and following RESTful principles.
There are two approaches that I have seen so far.
One is to map the action to a verb if there are very few actions so there is no collision. So if action is not safe nor idempotent then POST, otherwise if not safe but idempotent then PUT:
POST http://myhost/myservice/XYZ
Other is to define the action as a logical resource:
POST http://myhost/myservice/XYZ/Assignment
Later is richer and I favour that.
Few Important Points
RPC Endpoint -> REST Entry Point
RPC read method -> REST GET on Resource
RPC create method -> REST POST operation
PRC delete method -> REST DELETE operation
RPC SOAP Message -> REST PayLoad
additonaly , think about Cache headers , Content-Type headers like #Consumes, #Produces