How would I issue multiple cards without having them stack together? knowing that these cards are issued dynamically in my system. I can't go through the manual create certificate process each time.
How would that work?
For storecard passes, using different certificates is the only way to prevent grouping. storecard and generic passes with the same passTypeIdentifier will always be grouped together.
For other pass types such as eventTicket and boardingPass types, we could make use of groupingIdentifier key to separate passes with the same passTypeIdentifier into different groups.
groupingIdentifier
string
An identifier the system uses to group related boarding passes or
event tickets. Wallet displays passes with the same
groupingIdentifier, passTypeIdentifier, and type as a group. Use this
identifier to group passes that are tightly related, such as boarding
passes for different connections on the same trip.
Related
All e-mail templates in Shopware 6 reference the transactions payment name and current state by using the first collection entry order.transactions.first.paymentMethod.translated.name and
order.transactions.first.stateMachineState.translated.name.
Is the transaction sorting for e-mails different that the default sorting by createdAt?
Because according to all code examples I have found so far (e.g. AccountOrderPageLoader) the transactions are normally sorted by createdAt.
Based on the sortings I would expect e-mails to show a wrong payment method if the customer switches the payment method after ordering.
So my question is:
Shouldn't all e-mail templates reference the last entry of the transactions collection to really show the latest state? Or is the sorting for e-mails changed somewhere else?
Thanks for clarification.
I think this is a valid concern but given the standard procedures shouldn't become an issue. This is because when using the StateMachineRegistry to transition from one state to another, the existing state entity is being updated instead of a new one being inserted. So if the transition model is being used as it is intended, there should only be one state per combination of order and payment/delivery method that gets updated, with the former states being persisted as state_machine_history entities to retrace state changes.
Technically however, given that the associations are instances of OneToManyAssociationField, it is obviously possible to persist multiple entities of order_transaction or order_delivery per order when using the corresponding repositories. I think the reason for this relation model being used was to, in the future, potentially allow multiple delivery/payment methods when placing a single order. However this currently isn't implemented which is why it is important to use the proper services to transition between states as explained.
I am working on an application which requires some double entry bookkeeping. Currently there are two endpoints
/account
/transaction
While /account handles general data of the accounts, /transaction handles transactions for deposits/withdrawal. Account balance is calculated based on the related transactions. I kept them separated to get consistency in the bookkeeping when transferring value from one to another account.
My question is how to represent the balance of an account at the /account endpoint as it always will be calculated on request time. Should a response just contain the balance as a read-only field? This smells like bad API design since all fields but this one would be writeable/updateable.
The alternative coming to my mind would be to extend the endpoint to
/account/{id}/balance
returning only the balance of the regarding account. However, this would always require a second call to get the balance in addition to the remaining data of the account. Maybe the answer could generalized on how to represent aggregated values.
Very good question. I run into situations like this, often. I would say two things:
You probably have other "read-only" fields, like "id"
You may not want to incur the time it takes to calculate the current balance every time you get an account details.
I think I would opt for /account/{id}/balance ... but maybe name it /account/{id}/calculatebalance to indicate that it does take some time to run this methods. And, then it is obvious that the value is a calculated value. If you had "several" calculated values, then I would rethink my opinion.
2 cents.
You usually don't write aggregate properties, so it is natural that the property is read only. It is a sing that you are starting to have a service instead of a database with HTTP interface. Recalculating for each request is not necessary if you can cache it somewhere, though it depends on your needs. I see this is a very old question, idk. how I clicked on it.
There appear to be two lines of APIs for adding, authenticating and aggregating sites. Depending upon which version of the Documentation/SDK set your rep started you off on, or where in the SDK Guide you started implementing from determines where you start.
Path #1 starts at
ContentServiceTraversal which allows for the retrieval of all ContentServiceInfo (by container type (such as BANK)
ItemManagementService is used to add these items
Refresh is done through RefreshService (most API not containing the word Site)
Path #2 starts at
SiteTranversalService which allows for the retrieval of all SiteInfo (no apparent support for Container Type filter)
SiteAccountManagementService is used to add these items
Refresh is done through Refreshservice (all API containing the word Site).
From the best that I can tell the aforementioned API have a lot of functionality duplication. I have noticed certain API that exist on one branch and not the other but usually they are minor changes (e.g. things you are able to filter by).
I started off with ContentServiceInfo because the documentation and samples that our rep initially gave us started there. Additionally this API started off by providing greater granularity (e.g. simply being able to filter by Container type since we were pretty much only interested in Banks and Processor sites (which I do not believe you guys support)).
My questions are:
Do the two branches of API do the exact same thing?
Do they mostly behave the same way?
Do they back-end to the exact same
System
Data store
Scraper?
Is one line of API supposed to be deprecated sooner in the future than another?
Does one line of API have more future in terms of actually adding new or augmenting existing functionality?
Site-level addition has been introduced through Yodlee APIs to overcome the fact that though a user had bank,creditcard,loan,rewards account at the same end site, user had to provide credentials for each of these containers. Site level addition APIs try to add all these containers with only 1 set of credentials. That's the only difference between container based addition and site based addition.
As to answer your questions:
Do the two branches of API do the exact same thing?
Do they mostly behave the same way?
If you mean the aggregation functionality, Yes.Except for the fact that Site level adds/refreshes all the container(bank,creditcard,loan,rewards) and Container level can add/refresh only one container per API call, all the other behavior will remain the same.
Do they back-end to the exact same
System
Data store
Scraper?
If you are referring to the Yodlee data gathering components, Yes.
Is one line of API supposed to be deprecated sooner in the future than another?
No.Both these sets of APIs cater to different needs. If you are a company who solely rely on Creditcard data, using site level addition will be overkill as it will take longer time for the aggregation and it makes more sense to use container based addition. There is also the factor of backward compatibility, which rules out deprecation of APIs.
I'm trying to wrap my head around how to design a RESTful API for creating object graphs. For example, think of an eCommerce API, where resources have the following relationships:
Order (the main object)
Has-many Addresses
Has-many Order Line items (what does the order consist of)
Has-many Payments
Has-many Contact Info
The Order resource usually makes sense along with it's associations. In isolation, it's just a dumb container with no business significance. However, each of the associated objects has a life of it's own and may need to be manipulated independently, eg. editing the shipping address of an order, changing the contact info against an order, removing a line-item from an order after it has been placed, etc.
There are two options for designing the API:
The Order API endpoint intelligently creates itself AND its associated resources by processing "nested resource" in the content sent to POST /orders
The Order resource only creates itself and the client has to make follow-up POST requests to newly created endpoints, like POST /orders/123/addresses, PUT /orders/123/line-items/987, etc.
While the second option is simpler to implement at the server-side, it makes the client do extra work for 80% of the use-cases.
The first option has the following open questions:
How does one communicate the URL for the newly created resource? The Location header can communicate only one URL, however the server would've potentially created multiple resources.
How does one deal with errors? What if one of the associons has an error? Do we reject the entire object graph? How is that error communicated to the client?
What's the RESTful + pragmatic way of dealing with this?
How I handle this is the first way. You should not assume that a client will make all the requests it needs to. Create all the entities on the one request.
Depending on your use case you may also want to enforce an 'all-or-nothing' approach in creating the entities; ie, if something falls, everything rolls back. You can do this by using a transaction on your database (which you also can't do if everything is done through separate requests). Determining if this is the behavior you want is very specific to your situation. For instance, if you are creating an order statement you may which to employ this (you dont want to create an order that's missing items), however if you are uploading photos it may be fine.
For returning the links to the client, I always return a JSON object. You could easily populate this object with links to each of the resources created. This way the client can determine how to behave after a successful post.
Both options can be implemented RESTful. You ask:
How does one communicate the URL for the newly created resource? The Location header can communicate only one URL, however the server would've potentially created multiple resources.
This would be done the same way you communicate linkss to other Resources in the GET case. Use link elements or what ever your method is to embed the URL of a Resource into a Representation.
Currently I am developing an API and within that API I want the signed in users to be able to like/unlike or favorite/unfavorite two resources.
My "Like" model (it's a Ruby on Rails 3 application) is polymorphic and belongs to two different resources:
/api/v1/resource-a/:id/likes
and
/api/v1/resource-a/:resource_a_id/resource-b/:id/likes
The thing is: I am in doubt what way to choose to make my resources as RESTful as possible. I already tried the next two ways to implement like/unlike structure in my URL's:
Case A: (like/unlike being the member of the "resource")
PUT /api/v1/resource/:id/like maps to Api::V1::ResourceController#like
PUT /api/v1/resource/:id/unlike maps to Api::V1::ResourceController#unlike
and case B: ("likes" is a resource on it's own)
POST /api/v1/resource/:id/likes maps to Api::V1::LikesController#create
DELETE /api/v1/resource/:id/likes maps to Api::V1::LikesController#destroy
In both cases I already have a user session, so I don't have to mention the id of the corresponding "like"-record when deleting/"unliking".
I would like to know how you guys have implemented such cases!
Update April 15th, 2011: With "session" I mean HTTP Basic Authentication header being sent with each request and providing encrypted username:password combination.
I think the fact that you're maintaining application state on the server (user session that contains the user id) is one of the problems here. It's making this a lot more difficult than it needs to be and it's breaking a REST's statelessness constraint.
In Case A, you've given URIs to operations, which again is not RESTful. URIs identify resources and state transitions should be performed using a uniform interface that is common to all resources. I think Case B is a lot better in this respect.
So, with these two things in mind, I'd propose something like:
PUT /api/v1/resource/:id/likes/:userid
DELETE /api/v1/resource/:id/likes/:userid
We also have the added benefit that a user can only register one 'Like' (they can repeat that 'Like' as many times as they like, and since the PUT is idempotent it has the same result no matter how many times it's performed). DELETE is also idempotent, so if an 'Unlike' operation is repeated many times for some reason then the system remains in a consistent state. Of course you can implement POST in this way, but if we use PUT and DELETE we can see that the rules associated with these verbs seem to fit our use-case really well.
I can also imagine another useful request:
GET /api/v1/resource/:id/likes/:userid
That would return details of a 'Like', such as the date it was made or the ordinal (i.e. 'This was the 50th like!').
case B is better, and here have a good sample from GitHub API.
Star a repo
PUT /user/starred/:owner/:repo
Unstar a repo
DELETE /user/starred/:owner/:repo
You are in effect defining a "like" resource, a fact that a user resource likes some other resource in your system. So in REST, you'll need to pick a resource name scheme that uniquely identifies this fact. I'd suggest (using songs as the example):
/like/user/{user-id}/song/{song-id}
Then PUT establishes a liking, and DELETE removes it. GET of course finds out if someone likes a particular song. And you could define GET /like/user/{user-id} to see a list of the songs a particular user likes, and GET /like/song/{song-id} to see a list of the users who like a particular song.
If you assume the user name is established by the existing session, as #joelittlejohn points out, and is not part of the like resource name, then you're violating REST's statelessness constraint and you lose some very important advantages. For instance, a user can only get their own likes, not their friends' likes. Also, it breaks HTTP caching, because one user's likes are indistinguishable from another's.