what is wrong with this statement ??
98 views
Skip to first unread message
miqui
Apr 5, 2017, 10:57:04 AM4/5/17
to API Craft
Hi folks,
..i am came across this in a company API guidelines doc, and the first thing that came to mind was that this might conflict what microservice design... thoughts?
>>
We should avoid too Coarse Grained API that will end up being a service catalogue. We should also avoid having an approach where an API is created for each specific needs.
>>
rgds,
miqui
Ben Schaaf
Apr 5, 2017, 11:23:07 AM4/5/17
to api-...@googlegroups.com
Depending on the company and the purpose of their APIs, there may be exactly 0 things wrong with that statement.
--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.
David Raccah
Apr 26, 2017, 12:34:52 PM4/26/17
to API Craft
Actually, this is a thing I pound on often. What is the granularity of REST-based services? We can imagine that you have this domsin object (Domain meaning it is an enterprise domain object that is complex and aggregate in nature)
User 1->* Accounts 1->* Preferences
User 1->* Accounts 1->* ContantInfo 1->* contact options (address, phone, sms, email, etc)
Now, would we front this with the classic methodology of Microservices? Meaning we get a service for each entity? That sounds horrible to me, for one MAIN reason, how do we assure data consistency, when we want to add a new User, Account, and Preference? If we have three services, that would require three calls to get a single thing done. We could create three data/CRUD services and one aggregation service to do that for us, but the aggregation service would still be doing an underlying three phase commit! Which sounds horrible to me.
I would state that domain based services are easier to maintain, own, and version. It keeps the domain and its data ACID/BASE without having to do scary reconciliation stuff later on. With this, you would have more control on the actual number of services created.
The other way to see this is, well what if the services are not related at all - other than to user or some main high level concentration point. We do not want all services clumped under user or the concentration point.
In that case, yeah create them as simple and as small as possible - where the domain exists and do not clump/slam related services into each other.
mca
Apr 26, 2017, 12:48:03 PM4/26/17
to api-...@googlegroups.com
when it comes to designing/implementing "networked software" (e.g. software components that are aware of the network), i invoke the following mantra...
"Your data model is not your object model is not your resource model is not your representation model."
don't fall into the trap of exposing one of your internal models on the network (data, object) and make sure your external models (resources and representations) follow Alan Kay's "message" approach instead of RPC-style (SOAP) or OOP-style (CRUD) interfaces.
when i design my external interfaces (APIs) i focus on what API users want to get done, regardless of the internal models i have at the moment. those internal models are likely to change -- the things users want to get done are less likely to change -- and when they do i just create new APIs, not break the old ones.
then questions like granularity, "proper URLs", etc. take care of themselves.
hope this helps.
--
miguel quintero
Apr 26, 2017, 7:39:51 PM4/26/17
to api-...@googlegroups.com
.. thanks Mike . (btw, looking forward to RESTfest...) .... i think this topic could make a great 5by5
rgds
Miguel
--
You received this message because you are subscribed to a topic in the Google Groups "API Craft" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/api-craft/cpJeNyvXQKk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to api-craft+unsubscribe@googlegroups.com.
mca
Apr 26, 2017, 9:36:33 PM4/26/17
to api-...@googlegroups.com
Miguel:
yep,this would be a great thing to bring up at RESTFest in Greenville and Edinburgh this year.
looking forward to seeing you there!
Reply all
Reply to author
Forward
0 new messages