10 added 250 characters in body
source | link

I know you cannot have multiple gets according to REST

Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises introduced by Fielding on his dissertation about distributed architectural styles. These premises have nothing to do with how APIs are modelled, how many resources, URIs and semantics we provide.

For instance:

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users?q=living:coruscant
/api/users?q=id:12345
/api/user/12345
/api/me

Some of the above URIs might refer to the same resource(s), the main difference (and key point) lays on their respective semantics.

so does this solution still comply with the constraints for a RESTful service?

In my opinion, your approach is closer to an RPC-like web service than an API REST. Take a look at Martin Fowler's article about Richardson Maturity Model.

NoteIf we read Martin's post carefully, we find that Martin is not introducing API modelling techniques or best practices. He sets the focus on neither do a single reference to how APIs should be modelled nor what makes REST APIs good or badhow to make the communication client-server properly according to the HTTP semantics. How to represent and discover resources.

But, he does not mention how to identify these resources. He does not mention how to shape URIs.

And if not how can I make it truly RESTful?

If making the API totally RESTful is the concern, I would suggest reading Fielding dissertation first. Once assimilated the meaning of REST, I would look for documentation related to API modelling. As soon as the last agreed with the former you should be on the good path.

Here 2 links to start working:

The above links follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

I have emphasised the word conventions intendedly. These can be dismissed or interpreted if you consider them to be inadequate to your needs.


Further readings

If you are interested in the topic, I have found the following books to be insightful.

  • API Design Rulebook: It is mostly focused on the API modelling. You will find a brief introduction to the web architecture and to the REST principles.

  • Rest in practice: I consider this one to be more advanced. Rather focused on the advantages of REST as an integration than on API modelling.

I know you cannot have multiple gets according to REST

Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises introduced by Fielding on his dissertation about distributed architectural styles. These premises have nothing to do with how APIs are modelled, how many resources, URIs and semantics we provide.

For instance:

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users?q=living:coruscant
/api/users?q=id:12345
/api/user/12345
/api/me

Some of the above URIs might refer to the same resource(s), the main difference (and key point) lays on their respective semantics.

so does this solution still comply with the constraints for a RESTful service?

In my opinion, your approach is closer to an RPC-like web service than an API REST. Take a look at Martin Fowler's article about Richardson Maturity Model.

Note that Martin neither do a single reference to how APIs should be modelled nor what makes REST APIs good or bad.

And if not how can I make it truly RESTful?

If making the API totally RESTful is the concern, I would suggest reading Fielding dissertation first. Once assimilated the meaning of REST, I would look for documentation related to API modelling. As soon as the last agreed with the former you should be on the good path.

Here 2 links to start working:

The above links follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

I have emphasised the word conventions intendedly. These can be dismissed or interpreted if you consider them to be inadequate to your needs.


Further readings

If you are interested in the topic, I have found the following books to be insightful.

  • API Design Rulebook: It is mostly focused on the API modelling. You will find a brief introduction to the web architecture and to the REST principles.

  • Rest in practice: I consider this one to be more advanced. Rather focused on the advantages of REST as an integration than on API modelling.

I know you cannot have multiple gets according to REST

Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises introduced by Fielding on his dissertation about distributed architectural styles. These premises have nothing to do with how APIs are modelled, how many resources, URIs and semantics we provide.

For instance:

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users?q=living:coruscant
/api/users?q=id:12345
/api/user/12345
/api/me

Some of the above URIs might refer to the same resource(s), the main difference (and key point) lays on their respective semantics.

so does this solution still comply with the constraints for a RESTful service?

In my opinion, your approach is closer to an RPC-like web service than an API REST. Take a look at Martin Fowler's article about Richardson Maturity Model.

If we read Martin's post carefully, we find that Martin is not introducing API modelling techniques or best practices. He sets the focus on how to make the communication client-server properly according to the HTTP semantics. How to represent and discover resources.

But, he does not mention how to identify these resources. He does not mention how to shape URIs.

And if not how can I make it truly RESTful?

If making the API totally RESTful is the concern, I would suggest reading Fielding dissertation first. Once assimilated the meaning of REST, I would look for documentation related to API modelling. As soon as the last agreed with the former you should be on the good path.

Here 2 links to start working:

The above links follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

I have emphasised the word conventions intendedly. These can be dismissed or interpreted if you consider them to be inadequate to your needs.


Further readings

If you are interested in the topic, I have found the following books to be insightful.

  • API Design Rulebook: It is mostly focused on the API modelling. You will find a brief introduction to the web architecture and to the REST principles.

  • Rest in practice: I consider this one to be more advanced. Rather focused on the advantages of REST as an integration than on API modelling.

9 I have rephrased the answer to make it less ambiguous.
source | link

I know you cannot have multiple gets according to REST

Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises introduced by Fielding on his dissertation about distributed architectural styles. These premises have nothing to do with how APIs are modelled, how many resources, URIs and semantics we provide.

For instance:

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users?q=living:coruscant
/api/users?q=id:12345
/api/user/12345
/api/me

Some of the above URIs might refer to the same resource(s), regardless the differences ofmain difference (and key point) lays on their respective semantics.  

so does this solution still comply with the constraints for a RESTful service?

In my opinion, your approach is closer to an RPC-like web service than an API REST. Take a look at Martin Fowler's article about Richardson Maturity Model.

Note that Martin neither do a single reference to how APIs should be modelled nor what makes REST APIs good or bad.

And if not how can I make it truly RESTful?

If making the API totally RESTful is the concern, I would suggest reading Fielding dissertation first. Once assimilated the meaning of REST, I would look for documentation related to API modelling. As soon as the last agreed with the former you should be on the good path.

Here 2 links to start working:

The above links follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

Finally, keep always in mindI have emphasised the word conventions intendedly. These can be dismissed/interpreted at will or interpreted if you consider notthem to be enoughinadequate to meet your requirementsneeds.


Further readings

If you are interested in the topic, I have found the following books to be insightful.

  • API Design Rulebook: It is mostly focused on the API modelling. You will find a brief introduction to the web architecture and to the REST principles.

  • Rest in practice: I consider this one to be more advanced. Rather focused on the advantages of REST as an integration than on API modelling.

I know you cannot have multiple gets according to REST

Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises introduced by Fielding on his dissertation about distributed architectural styles. These premises have nothing to do with how APIs are modelled, how many resources, URIs and semantics we provide.

For instance:

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users?q=living:coruscant
/api/users?q=id:12345
/api/user/12345
/api/me

Some of the above URIs might refer to the same resource(s), regardless the differences of their respective semantics.  

so does this solution still comply with the constraints for a RESTful service?

In my opinion, your approach is closer to an RPC-like web service than an API REST. Take a look at Martin Fowler's article about Richardson Maturity Model.

Note that Martin neither do a single reference to how APIs should be modelled nor what makes REST APIs good or bad.

And if not how can I make it truly RESTful?

If making the API totally RESTful is the concern, I would suggest reading Fielding dissertation first. Once assimilated the meaning of REST, I would look for documentation related to API modelling. As soon as the last agreed with the former you should be on the good path.

Here 2 links to start working:

The above links follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

Finally, keep always in mind the word conventions. These can be dismissed/interpreted at will if you consider not to be enough to meet your requirements.


Further readings

If you are interested in the topic, I have found the following books to be insightful.

  • API Design Rulebook: It is mostly focused on the API modelling. You will find a brief introduction to the web architecture and to the REST principles.

  • Rest in practice: I consider this one to be more advanced. Rather focused on the advantages of REST as an integration than on API modelling.

I know you cannot have multiple gets according to REST

Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises introduced by Fielding on his dissertation about distributed architectural styles. These premises have nothing to do with how APIs are modelled, how many resources, URIs and semantics we provide.

For instance:

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users?q=living:coruscant
/api/users?q=id:12345
/api/user/12345
/api/me

Some of the above URIs might refer to the same resource(s), the main difference (and key point) lays on their respective semantics.

so does this solution still comply with the constraints for a RESTful service?

In my opinion, your approach is closer to an RPC-like web service than an API REST. Take a look at Martin Fowler's article about Richardson Maturity Model.

Note that Martin neither do a single reference to how APIs should be modelled nor what makes REST APIs good or bad.

And if not how can I make it truly RESTful?

If making the API totally RESTful is the concern, I would suggest reading Fielding dissertation first. Once assimilated the meaning of REST, I would look for documentation related to API modelling. As soon as the last agreed with the former you should be on the good path.

Here 2 links to start working:

The above links follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

I have emphasised the word conventions intendedly. These can be dismissed or interpreted if you consider them to be inadequate to your needs.


Further readings

If you are interested in the topic, I have found the following books to be insightful.

  • API Design Rulebook: It is mostly focused on the API modelling. You will find a brief introduction to the web architecture and to the REST principles.

  • Rest in practice: I consider this one to be more advanced. Rather focused on the advantages of REST as an integration than on API modelling.

8 I have rephrased the answer to make it less ambiguous.
source | link

Not really. RESTREST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises dissertedintroduced by Fielding on his dissertation about distributed architectural styles.

  These premises have nothing to do with how APIs are shaped. What decide how APIs are modelled, how many GETsresources, URIs and semantics we need are our needs (requirements)provide.  

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users?q=living:coruscant
/api/users?q=id:12345
/api/user/12345
/api/me

Note that /api/me and /api/1234Some of the above URIs might refer to the same resource(s), regardless the differences of their respective semantics.

This is what matters (regarding REST). The resources we want to expose, the representation and the semantics of their identifiers (URIs).

To meIn my opinion, your approach is closer to an RPC-like web service than an API REST. Take a look at Martin Fowler's article about

I could explain why, but I leave it to someone who has more credibility and already summarised it quite wellRichardson Maturity Model.

Note that Martin neither do a single reference to how APIs should be modelled nor what nor what makes REST APIs good or bad.

That's quite a good question and it hasn't easy answer. You will find several blogs, articlesIf making the API totally RESTful is the concern, sites and books out there that cover this subjectI would suggest reading Fielding dissertation first.

It's difficultOnce assimilated the meaning of REST, I would look for documentation related to design what your colleague has described good REST APIsAPI modelling. Good and best depends onAs soon as the needs andlast agreed with the requirements. For example,former you should be on the AWS' and Netflix' APIs are quite different and they are consumed by thousands (world wide)good path.

Nevertheless, hereHere 2 links to start working:

  • Resource naming conventions Quite basic. Some of the conventions introduced here are broadly accepted as "good practices".

    Keep always in mind the word conventions. These can be dismissed/interpreted if they prove to be not enough.

  • API modelling Here, we delve into the API modelling.

All theThe above links, follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

Finally, keep always in mind the word conventions. These can be dismissed/interpreted at will if you consider not to be enough to meet your requirements.


Further readings

If you are interested in the topic, I have found API Design Rulebook and Rest in practice books insightful and useful.

The first is mostly focused on the API modelling. You will find a brief introduction to the web architecture (probably, the most important subject here) and the REST principles.

The second one I consider itfollowing books to be more advanced. Not so focused on the modelling process. Instead, it focuses on showing up the potential of REST as an integration strategyinsightful.

  • API Design Rulebook: It is mostly focused on the API modelling. You will find a brief introduction to the web architecture and to the REST principles.

  • Rest in practice: I consider this one to be more advanced. Rather focused on the advantages of REST as an integration than on API modelling.

Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy based on the premises disserted by Fielding on his dissertation about distributed architectural styles.

  These premises have nothing to do with how APIs are shaped. What decide how many GETs we need are our needs (requirements).  

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users
/api/user/12345
/api/me

Note that /api/me and /api/1234 might refer to the same resource, regardless the differences of their respective semantics.

This is what matters (regarding REST). The resources we want to expose, the representation and the semantics of their identifiers (URIs).

To me, your approach is closer to an RPC-like web service than an API REST.

I could explain why, but I leave it to someone who has more credibility and already summarised it quite well.

Note that Martin neither do a single reference to how APIs should be modelled nor what makes REST APIs good or bad.

That's quite a good question and it hasn't easy answer. You will find several blogs, articles, sites and books out there that cover this subject.

It's difficult to design what your colleague has described good REST APIs. Good and best depends on the needs and the requirements. For example, the AWS' and Netflix' APIs are quite different and they are consumed by thousands (world wide).

Nevertheless, here 2 links to start working:

  • Resource naming conventions Quite basic. Some of the conventions introduced here are broadly accepted as "good practices".

    Keep always in mind the word conventions. These can be dismissed/interpreted if they prove to be not enough.

  • API modelling Here, we delve into the API modelling.

All the above links, follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

If you are interested in the topic, I have found API Design Rulebook and Rest in practice books insightful and useful.

The first is mostly focused on the API modelling. You will find a brief introduction to the web architecture (probably, the most important subject here) and the REST principles.

The second one I consider it to be more advanced. Not so focused on the modelling process. Instead, it focuses on showing up the potential of REST as an integration strategy.

Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises introduced by Fielding on his dissertation about distributed architectural styles. These premises have nothing to do with how APIs are modelled, how many resources, URIs and semantics we provide.

/api/users-living-in-courscant
/api/users-not-living-in-courscant
/api/users?q=living:coruscant
/api/users?q=id:12345
/api/user/12345
/api/me

Some of the above URIs might refer to the same resource(s), regardless the differences of their respective semantics.

In my opinion, your approach is closer to an RPC-like web service than an API REST. Take a look at Martin Fowler's article about Richardson Maturity Model.

Note that Martin neither do a single reference to how APIs should be modelled nor what makes REST APIs good or bad.

If making the API totally RESTful is the concern, I would suggest reading Fielding dissertation first. Once assimilated the meaning of REST, I would look for documentation related to API modelling. As soon as the last agreed with the former you should be on the good path.

Here 2 links to start working:

The above links follow a deliberated order. I think it's a natural order that goes from basics to advanced concepts. From the ground up.

Finally, keep always in mind the word conventions. These can be dismissed/interpreted at will if you consider not to be enough to meet your requirements.


Further readings

If you are interested in the topic, I have found the following books to be insightful.

  • API Design Rulebook: It is mostly focused on the API modelling. You will find a brief introduction to the web architecture and to the REST principles.

  • Rest in practice: I consider this one to be more advanced. Rather focused on the advantages of REST as an integration than on API modelling.

7 added 556 characters in body
source | link
6 added 1 character in body
source | link
5 Referring to books (or other external resources) as further reading in a good answer is not off topic. Only if it is the main content of the answer.
source | link
4 spellcheck revision
source | link
3 edited body; deleted 6 characters in body
source | link
2 added 280 characters in body
source | link
1
source | link